> On 2020-08-27 00:05, Yang Wang wrote:
> Hello Göran,
> I am cross-posting to ISOBlue Google Group to continue our
> The bigger picture on ISOBlue with Avena is encapsulated in the
> architecture figure of this document
> short, we hope to create an ag machinery sensor hub/ecosystem.
> Sensors provide data streams. Services are written to back up data,
> push data to Cloud, do edge computing, etc.
In my opinion it would *not* be a good idea to push the complete CAN datastream
to the "cloud".
In an machine there is a _lot_ going on that you are _not_ interested in.
The CAN bus itself is a message buss and contains all sort of communications
between all units. Ant that could be a lot of them. So before starting
to collect data you must set upp some sort of filter and _then_ start
And the idea behind the CAN buss is "problem separation". Eatch node on the
CAN unit does one thing and do that thing well. I belive that a monitoring
system should follow this paradigm. Not to cram all kind of functionality
into one linux box.
> How services are written
> is up to the user. For example, if you only need yield data, you will
> write a service that parse yield data out from the CAN stream and do
> whatever you want with it.
And this is also a problem. The CAN-stream from a agricultural machine
is encoded as ISO11783-10 messages. And this is a quite large "application"
protocol and _not_ easy to decode.
> In terms of price, for a complete last gen ISOBlue unit, it costs
> about $1000. However, with the Avena stack, this might get much
> cheaper or expensive depending on what you need to achieve. Since
> Avena aims to be as generic as possible, you could probably install
> it on a Raspberry Pi to do some basic logging. However, if your goal
> is to do video processing on the fly, a more powerful (expensive)
> solution should be considered.
On a agricultural machine there is a lot of power. And there
is lot of space. If you are planing to use a Unix (Linux) system
there is no need for a Rasberry. You could go for a industrial computer.
You could use a CAN interface to this and an ordinary USB stick for GSM
> For your comments on parsing CAN logs, there are a number of existing
> solutions (1 <https://github.com/eerimoq/cantools
>, 3> <https://github.com/commaai/opendbc
>) targeting road vehicles. The
> trick is to generate dbc files - a file that stores message
> definitions. These dbc files are typically not machine agnostic;
> meaning that you will probably need a number of these files across
> different machines and brands. We are pretty good at logging CAN from
> machines; parsing CAN is an area we also want to tackle on.
Yes - and this is precise the problem. Most of the projects you list are
for ordinary cars or trucks. Most car manufacturer have there own application
protocol. And that for a good reason. If you know the application protocol
you could also inject data and by that havoc the engine.
And I found no parsing of ISO11783.
> Related to GeodataFarm, we have similar tools in OpenATK
> and ISOBlueApp
> (live app
>) is related to ISOBlue. They serve
> to visualize both real-time and historic data (GPS, yield, etc.). The
> backend is powered by our own OADA API <https://github.com/oada
> These works are actively maintained.
Ok. I will look at this.
> Also thanks for your catch on the dependency error. We are slowly
> moving away from using Kafka in logging CAN to a more compact
> solution using just candump
In my opinion the parser of data should be as close to the CAN bus as possible.
Ofcourse this needs some sort of configuration before eatch run. But to store
a compleat CAN-stream would be overkill. So in Unix pipe lingo this
CAN-unit | socketcan/can-card | ISO11783-filter (c-program) | local storage (SSD) | transport(GSM) | longtime storage (Postgresql)
> This is quite a bit of information but hopefully they will help you
> guys out. We definitely would like to collaborate on creating a CAN
> parser. We have quite a bit of past CAN logs to play with. Let us
> know what you think.
Yes. And I hope I can contribute to your project.
>> I am interested in your ISO-Blue project. I tried to read on the
>> isoblue-avena homepage (GitHub) but did not understand the
>> relation between
>> isoblue and avena?
>> I checked out hte git but did not fine any source code...
>> How to proceed?
>> // GH
>> Göran Hasse
>> email: gor...@raditex.nu
> 070 5530148 mail: gor...@raditex.nu