The First Dutch ISOBlue!


#1

As of a few days ago, we got all the parts we need. So we started building the IsoBlue ofcourse:

IMG_20180805_105357763|666x500

Looking good thus far. Will do some updates from time to time in this topic.

p.s. how to properly put in pictures?


About the ISOBlue project
About the ISOBlue project
Challenge 4: Trekkerdata over bodemverdichting
#2

Also trouble: what are the electrical connections to make between the ISOBus connector and the Ixora board?

In the Ixora documentation I can’t find out which pin is the first pin for X20, I assume top left to be the first:

As for the ISOBus connector, I came across this:


I assume this document is correct?

I also assume pins:

  • A+B to be the power supply for the board => A as GND, B as V+
  • C+D to be connected to can2 => C to CAN2_H, D to CAN2_L
  • H+I to be connected to can1 => H to CAN1_H, I to CAN1_L

Need a little help here!

Ok, with the Ixora schematics i found the pinout:
https://docs.toradex.com/104005-ixora-v1-1-schematics.zip
Top left is 1, top right is 2, middle left is 3, middle right is 4, bottom left is 5, bottom right is 6.
Giving:
1 Can1_L……2 Can1_H
3 Can1_GND…4 Can2_GND
5 CAN2_H…
…5 Can2_L

Next level:


CAN Bus is 2 wire, meaning it doesn’t need GND. Updated the above connections. Still not sure which CAN to connect to implement bus and tractor bus…


#3

Hello Roel,

Top left is 1, top right is 2, middle left is 3, middle right is 4, bottom left is 5, bottom right is 6.
Giving:
1 Can1_L……2 Can1_H
3 Can1_GND…4 Can2_GND
5 CAN2_H……5 Can2_L

This is correct. If you look closely enough, there is a silkscreen of a white dot above pin 1 of the CAN header. This should help you identify which one is pin 1.

For your questions on connections:

I assume this document is correct?

First please note there is no pin I in the ISOBUS headers that we purchased. I don’t know if there is a typo in the document or there is simply another version of the ISOBUS header that has pin I. And I don’t why they skipped pin I in the first place.

I normally refer to this pin out diagram for the ISOBUS connections:

Also trouble: what are the electrical connections to make between the ISOBus connector and the Ixora board?

I also assume pins:

A+B to be the power supply for the board => A as GND, B as V+
C+D to be connected to can2 => C to CAN2_H, D to CAN2_L
H+I to be connected to can1 => H to CAN1_H, I to CAN1_L

For the current ISOBlue2 software, we have the following connections:

A+B to be the power supply for the board => A as GND, B as V+
C+D to be connected to can1 => C to CAN1_H, D to CAN1_L
H+J to be connected to can2 => H to CAN2_H, I to CAN2_L

Let me know if this helps!


#4

@wang701, your reply was very helpfull, the IsoBlue is now assembled.

I’m currently here with Auke (recently returned from holiday) trying to build the software or to use the prebuilt image, but we can’t seem to figure it out…

With building the software ourselves we get stuck with a repo which doesn’t like to sync


Auke will post the CLI output.

The prebuild image is also troublesome, since some files seem to be missing in the .img file

The following content should be available according to the instructions:
extracted-dir
└── apalis-imx6_bin
└── imx_flash
└── mnt
└── rootfs
update.sh

Content of the .img:
apalis-imx6 (folder)
flash_blk.img
flash_eth.img
flash_mmc.img

This content is completely different from what is described. In the instructions is also a reference to “update.sh” which seems to be missing with the prebuilt .img.

Perhaps you can shine a light on it?


#5

Hi Yang,

I have added the output from the repo sync operation below. Can you have a look at it and offer your suggestions on what’s going on? To me it seems there’s a problem fetching the right source files from the repo’s.

auke@ubuntu:~/isoblue-core$ repo sync -f --force-sync --no-repo-verify
Fetching project meta-lxde.git
Fetching project meta-isoblue-demos
Fetching project meta-oracle-java
Fetching project meta-qt5.git
Fetching project meta-isoblue
Fetching projects: 11% (2/18) Fetching project meta-jetson-tk1.git
error: Cannot fetch meta-oracle-java (GitError: meta-oracle-java update-ref: fatal: 14f4c87e70f58c2cfd30f8571a0769f8f44d58da^0: not a valid SHA1
)
Exception in thread Thread-3:
Traceback (most recent call last):
File “/usr/lib/python2.7/threading.py”, line 801, in __bootstrap_inner
self.run()
File “/usr/lib/python2.7/threading.py”, line 754, in run
self.__target(*self.__args, **self.__kwargs)
File “/home/auke/isoblue-core/.repo/repo/subcmds/sync.py”, line 270, in _FetchProjectList
success = self._FetchHelper(opt, project, *args, **kwargs)
File “/home/auke/isoblue-core/.repo/repo/subcmds/sync.py”, line 314, in _FetchHelper
prune=opt.prune)
File “/home/auke/isoblue-core/.repo/repo/project.py”, line 1271, in Sync_NetworkHalf
self._InitMRef()
File “/home/auke/isoblue-core/.repo/repo/project.py”, line 2364, in _InitMRef
self._InitAnyMRef(R_M + self.manifest.branch)
File “/home/auke/isoblue-core/.repo/repo/project.py”, line 2376, in _InitAnyMRef
self.bare_git.UpdateRef(ref, dst, message=msg, detach=True)
File “/home/auke/isoblue-core/.repo/repo/project.py”, line 2673, in UpdateRef
self.update_ref(*cmdv)
File “/home/auke/isoblue-core/.repo/repo/project.py”, line 2747, in runner
(self._project.name, name, p.stderr))
GitError: meta-oracle-java update-ref: fatal: 14f4c87e70f58c2cfd30f8571a0769f8f44d58da^0: not a valid SHA1

Fetching project openembedded-core.git
Fetching projects: 16% (3/18) Fetching project meta-angstrom.git
warning: redirecting to https://github.com/meta-qt5/meta-qt5.git/
Fetching projects: 22% (4/18) Fetching project bitbake.git
warning: redirecting to https://github.com/watatuki/meta-jetson-tk1.git/
Fetching projects: 27% (5/18) Fetching project meta-toradex-bsp-common.git
warning: redirecting to https://github.com/Angstrom-distribution/meta-angstrom.git/
warning: redirecting to https://github.com/openembedded/openembedded-core.git/
Fetching projects: 33% (6/18) Fetching project meta-openembedded.git
Fetching projects: 38% (7/18) Fetching project meta-qt5-extra.git
warning: redirecting to https://github.com/openembedded/bitbake.git/
Fetching projects: 44% (8/18) Fetching project meta-toradex-nxp
Fetching projects: 50% (9/18) Fetching project meta-freescale-distro.git
Fetching projects: 55% (10/18) Fetching project meta-freescale.git
warning: redirecting to https://github.com/Freescale/meta-freescale-distro.git/
Fetching projects: 61% (11/18) Fetching project meta-qt4
warning: redirecting to https://github.com/openembedded/meta-openembedded.git/
warning: redirecting to https://github.com/schnitzeltony/meta-qt5-extra.git/
Fetching projects: 66% (12/18) Fetching project meta-browser.git
Fetching projects: 72% (13/18) Fetching project meta-freescale-3rdparty.git
Fetching projects: 77% (14/18) warning: redirecting to https://github.com/Freescale/meta-freescale.git/
Fetching projects: 83% (15/18) warning: redirecting to https://github.com/OSSystems/meta-browser.git/
warning: redirecting to https://github.com/Freescale/meta-freescale-3rdparty.git/
Fetching projects: 94% (17/18)
error: Exited sync due to fetch errors

Thanks in advance!

Auke


#6

Hello Roel and Auke,

There was a problem with one of the commit ids for meta-oracle-java. I fixed it and you guys should be able to sync the repo now.

The prebuild image is also troublesome, since some files seem to be missing in the .img file

There is no file missing in the .img file. The content in the img file is the content of what you will see on your microSD card after you run update.sh to prepare the microSD card. To use the .img file, the most straightforward way is to use dd command to pipe the content to your SD card, for example:

sudo dd bs=1M if=isoblue.img of=/dev/sdx

where /dev/sdx is your SD card device.


#7

Hi @wang701 ,

Thanks for your quick response yesterday, we got much further using the .img.

Building the software ourselves failed for now, Auke will post his CLI output.

We have a few questions for setting up an internet connection;

We use a different modem for the EU, this is a different version: LE910-EU V2 and seems to be supported from kernel 4.6-rc2 and upwards:

We can’t seem to figure out how to upgrade the kernel (current: 4.1.39) though and haven’t found a workaround yet.

The wireless interface with the Edimax EW-7811Un is supposed to work out-of-the-box since kernel version 3.10 but we don’t know how to make it function.

Using the wired network works out-of-the-box, we therefore can carry out updates and such if that’s any usefull for a solution.

Could you please shine your light again? Much appreciated!

Sorry for all the questions, Auke and me have just a basic understanding of Linux.


#8

Hi Yang,

Thanks for your quick response!
There was quite some output when I ran the build command so here’s the link to a text file on google drive:

Bitbake output

Also, as we have the “Tractor Hackaton” next weekend, I think it would be good to have a skype call somewhere next week, and work out some details / questions we have. Do you think you have time to do so?
During the regular work hours your time would be excellent for us as it will be afternoon here and I’ll have time.
I think I should be able to set up SSH and you will be able to log in to the device as well.

Please let us know :slight_smile:

Thanks so far!


#9

Hello Roel,

It looks like cdc-ncm support for the LE910 was added from 4.6 and onwards but for both the prebuilt image as well as the bitbaked image, the corresponding kernel driver is called the QMI WWAN driver. So the kernel in the prebuilt image should be able to see this module if the driver supports the device.

The prebuilt image is also packaged with qmicli which is used to register the cell module on the network. It can be also used for checking if the device is available. For commands, please check this.

Some questions for you:

  • What do you see when you run lsusb?
  • Do you see any wwan device after you run ifconfig?

The prebuilt image doesn’t come with the kernel modules of the Edimax dongle. For both upgrading the kernel and enabling the kernel modules for the Wifi dongle, you will need to compile the linux kernel for apalis-im6 and then flash it onto your board. For the kernel compilation and flashing instructions, please see Toradex’s tutorial:

https://developer.toradex.com/knowledge-base/build-u-boot-and-linux-kernel-from-source-code

Before the kernel compilation, you need to have both QMI driver and EW-7811Un driver enabled from menuconfig and make sure you follow Toradex’s instructions for set up the right path for gcc and targets.


#10

Hello Auke,

I did some Google search on the error message. It looks like it is mostly the host version (you are running Ubuntu 18.04) that caused it. Please see:


My environment runs Ubuntu 16.10 and it seems like older version like 16.10 or 16.04 have better luck in this.

I also noticed another error when trying bitbaking the image myself. Just fixed it and I can successfully bitbake an image. Please remove the contents of your isoblue-core (but not .repo directory) and do a repo sync. I forgot to mention that the current image is on Toradex’s version 2.8b2 and it is still quite buggy as of the ISOBlue build party in May. This version is mapped to the latest Toradex hardware but I haven’t gotten around to work on it since.

If it doesn’t work, I have a backup branch called v2.7. This branch contains the stable software and kernel (but it still doesn’t have Wifi module enabled so you guys will still need to recompile the kernel after flashing in the image). To use this image, please remove the contents of your isoblue-core as well as .repo this time and do:

repo init -u https://github.com/ISOBlue/isoblue-image -b v2.7

The rest of the bitbake commands will be the same.


#11

Hello Auke,

Totally forgot to reply to that in the previous post. Yes, I am free except for 12:30 pm to 1:20 pm EST MTF and 4:30 pm to 5:45 pm ThF.


#12

Hi Yang,

We’ve run the commands and I think I understand the problem now.
As I’ve read here it seems that the device is actually recognized properly, but as usb0.

Blockquote[quote=“wang701, post:9, topic:50”]
The prebuilt image is also packaged with qmicli which is used to register the cell module on the network. It can be also used for checking if the device is available. For commands, please check this.

Some questions for you:

  • What do you see when you run lsusb ?
  • Do you see any wwan device after you run ifconfig ?
    [/quote]

When we run lsusb we get the following output:

root@apalis-imx6:/# lsusb
Bus 002 Device 003: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
Bus 002 Device 005: ID 1bc7:0036 Telit Wireless Solutions 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@apalis-imx6:/# 

It seems that both the wireless usb and the LTE modem are recognized.

Regarding the wwan device, the output of ifconfig is this:

root@apalis-imx6:/# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:14:2D:4F:65:E6  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1%1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

usb0      Link encap:Ethernet  HWaddr 00:00:11:12:13:14  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@apalis-imx6:/# 

I can imagine scripts running during boot refer the wwan0 interface, resulting in an error.
Is there any place we can / should correct this?

In the meantime I will be trying out bitbaking on ubuntu 16.04 :stuck_out_tongue:

Thanks again for your help!


#13

Hello Auke,

This should be right as for my ISOBlues, the Telit modems are seen as a usb device as well.

usb0      Link encap:Ethernet  HWaddr 00:00:11:12:13:14  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I don’t know if this is right. If the kernel driver for the qmi device works correctly, the device should be usually registered as a wwan0 interface.


#14

Hello Auke and Roel,

I bitbaked and tested another isoblue2 image on the newest Toradex hardware (Apalis V1.1C and Ixora V1.1A). This one contains the kernel modules for the cell module as well as the Wifi dongle. You can use the same dd command to clone the .img content to a microSD card and begin the flashing process.

The image file is at: https://drive.google.com/open?id=1phPlzAuKKq5TYcH0b05AxANMZaQciW81

Note: since we already have some work done on the dutch ISOBlue2, we will only update the kernel image and the device tree.

To do so, interrupt the boot sequence after you turn on the ISOBlue2 and run:

setenv fdt_file imx6q-apalis-ixora.dtb
saveenv

Power off the device and interrupt the boot sequence after you turn the ISOBlue2 back on, then run:

run setupdate
run update_kernel
run update_fdt

And these are done, run boot to continue the boot sequence.

If you are confused about these steps, I will walk you through them in the Wednesday Skype call.


#15

Hi all, I heard from @Anne that you managed to log some data yesterday at the hackathon! That’s awesome, congratulations! :tada:

Can you share some info and maybe some data? :hugs:


#16

I find your solution very interesting. Is there something I can help with?


#17

Hi All,

During the hackaton we have succesfully hooked up the IsoBlue to the tractor at the Fleuren tree nursery.
The data logs from the CAN bus and GPS can be found here

The tutorial for getting the data out of the device (and kafka) worked well, so now we have tho log files above.

@wang701
It seems the data coming out of kafka is in bytes (for the CAN).
Can you explain how we can convert this to regular text?

@derk
We’re still looking to understand the data that was logged at the hackaton, but as soon as we do, we’d be interested in hooking it up to other tractors and try to get out the important sensor data such as the hinge data. If we could use your tractors for these tests, that would be ideal!

I realise most of the posts above are a bit cryptic and short on info, as we were very busy lately.
I hope to add some more detail in the next few weeks.


Can we legally publish code implementing ISO-11783?
#18

Ok, we will see what it will bring. I have 2 Case tractors with canbus. Pieter has a Massey Fergison with canbus


#19

Hello Auke,

That’s pretty awesome!

This is the fun (sometimes frustrating) part of the whole ag machine data collection and parsing process. First off, one thing to clarify: although we have a slight word abuse on the term “CAN”, the messages you are getting from the tractor and the implement buses are not CAN messages. they are ISOBUS messages which are based on extended CAN frame format. In the specifications for ISOBUS (ISO 11783-3), you will find related information on the specific data formats and definitions.

The tra.log you have have three space-separated fields: timestamp, Parameter Group Number (PGN), data payload hex string. The timestamp is the Linux epoch timestamp when the message was collected. The data payload is the ISOBUS message. The PGN is parsed from a part of the data payload and it specifies the meaning of the rest of the data payload (for instance, PGN 61444 means engine RPM data). However, the unfortunate part here is, for our group, we have a Excel sheet that gives us mappings of PGNs, their meanings, and how to parse specific data payload byte/bit values into useful numbers and the sheet can only be used within our group. What’s frustrating sometimes is, our sheet only contains a fraction of all the ISOBUS messages and their definitions. Most PGNs and the information on how to parse data are proprietary and exclusive to each manufacturer. As a result, each time when we collect a new set of data, only a fraction of the data is parsed out and visualized and rest remain a mystery. Another issue here is that different manufacturers sometimes use the same PGN for different messages. For example, say for a CASE tractor, PGN 12345 means engine load but on another brand PGN 12345 means engine intake pressure.

Sorry I cannot give you an straight answer to this question but hopefully these background help.


Can we legally publish code implementing ISO-11783?
#20

Hello Wang701,

If I get your answer right: It’s up to ourselves to find the meaning of different PGNs. Do you know if there is a software tool that can help analysing data so that we can determine which PGN is for what purpose?