Mariano,
Thanks for reading and spending time to answer
I took a quick for open source ARINC libraries. Seems to be some
ARINC libraries around but nothing for the 800 series.
Comments on comments below.
Please let me know if you do not understand something again. I will
try and explain myself better.
Regards Matt
On Mar 10, 3:46 pm, malife <
mal...@gmail.com> wrote:
> Please find my comments inlined below
>
> On Thursday, March 10, 2011 12:47:04 AM UTC-6, crashmatt wrote:
>
> > If we have to buy a copy of the ARINC specification, does it mean that
> > it is not open source?
> > Does this mean that the open source community can not use it?.
>
> This is a great question and I think both answers are: no, we can not buy
> one copy and then make the implementation publicly available. Otherwise,
> someone already would have bought the standard and published a library.
>
> > This is the scheme I now prefer:
> > 1. No data packets are longer than the CAN data packet
>
> I think this is quite a restriction. For instance, I like what you propose
> on point 5, but announcing a list of resources with only 8 bytes is
> virtually impossible, or maybe I misunderstood the meaning of point 5.
>
This is still possible by using arrays of elements. As long as each
of the elements in the array is not bigger than the 8 byte CAN
message, it works ok.
Each thing in the array can be a collection of variables. Say a servo
status message could be:
Channel: 1 byte
Set Position: 2 bytes
Actual Position: 2 bytes
Current: 1 byte
Voltage: 1 byte
Temperature: 1 byte
= 8 bytes total
For a resource list the elements could be shorter. With elements
shorter than 4 bytes you can pack two or more into a CAN message.
pros:
No connections and receive buffers required
cons:
writing the code to handle the arrays is not so easy.
> 2. No connection is required, communication is based on broadcast only
>
>
>
> Yes, this is important and makes onboard implementation simple and requires
> very little resources.
>
This connectionless scheme was implemented on a UDB2 which had no
space left for any receive buffer of any sort.
I am not at all sure this is significant any more. We are unlikely to
be using processors with that little capacity again.
> > 3. Data requests are not normally performed. Control data is sent at
> > regular intervals.
>
> Yes, once again except for point 5.
>
> > 4. Each node has a unique address for identification by cli or over
> > MAVlink
>
> Could you expand on this a little bit? Do you mean that component-system ID
> be unique across MAVLink and MAVCANLink?
>
> > 5. Each node will present a list of resources on request.
>
> What I understand from this point is something like the current parameter
> interface, where, upon request, a node announces which resources it has
> available.
>
Excellent. Must read up on this bit.
> 6. All node resource types have an XML descriptor so that MAVlink/GCS
>
> > can understand what the resource is.
>
> Can you elaborate on this? I don't understand what you mean.
More like a description of physical attributes. For example, a sensor
or actuator has an IO range.
>
> > 7. Each resource type has a set of messages that it supports. These
> > are described in XML.
>
> Yes, very much like Mavlink
>
> > 8. Each resource on a node will be allocated a channel independent of
> > the node address.
>
> Not sure what you mean by a "channel", do you mean an acceptance filter? a
> buffer?
See 9 below
>
> > 9. For servo and radio connections the channel is the same as the RC
> > radio channel
>
> Again, please elaborate on what you mean by channel
>
Channel = standard radio channel as we think of it in RC radio
equipment
Channel 1 = Pitch, Channel 2 = Roll or
Channel 1 = Elevator, Channel 2 = left aileron etc...
The alternative is for a servo to be known as node address xx,
resource #n
The community is used to working with channel numbers. A scheme that
is familiar would be adopted more easily.
Does this make sense?