uBlox GPS with i2c

[Nanoseb]

So, today we (Camil and I) have played a bit more with the GPS and i2c. A couple of things can be noted. First i2c seems to be smart enough and there is no way of having clash of data with imu's for example (it was fun to see that with the logic analyser: imu message in the middle of the GPS ones ;) )

Secondly, we have about 40% of the gps messages that do not pass the checksum. It is only one or two characters that are not read correctly but that makes the message harder to parse so what to do with that:

• is it an issue? can we just assume that the GPS will work at half of its frequency and still be fine
• since only a couple of the characters are not good can we write a parser that will be more robust, the probability that the actual GPS coordinates are not readable is even lower

A last thing to consider is that with i2c we can't reprogram the chip, this means that we probably need to have the 2 serial pins accessible in case we need that.

The code we used to test the GPS is there: https://github.com/Maritime-Robotics-Student-Society/sailing-robot/blob/master/utilities/test_i2c_gps.py

@tsaoyu or @takluyver maybe? an idea?

If i2c isn't good enough we can still use the serial for the GPS, but we are avoiding that because it adds 2 cables to the top of the mast.

[takluyver]

If it's purely random, it's probably fine to skip the corrupted messages and accept a lower frequency. If there are blocks of several seconds where all the messages are corrupted, that might be more of a problem, depending on what the boat is doing at the time.

I'd say it's a bad idea to make the parser more 'robust' and try to use corrupted data: sooner or later, the corruption will give you a valid coordinate that's hundreds of miles out.

Was the 40% error rate with a long connection or a short one? Does it increase with the wire length? Are there things we can do (e.g. twisting wires together) that might improve the reliability? I've got no idea what sort of signals i2c uses.

[Nanoseb]

Yes, it looks random, but an other thing that will be interesting to analyse is the actual rate that we can achieve.

Also we will need to try outside with actual GPS data, here messages were quite empty, with longer messages maybe the probability of them being corrupted is higher.

The 40% were gathered with long wires, and they were twisted even if in this case it shouldn't have an impact on the signal.

Concerning having a more "robust" parser, ok yes it is probably a bit dangerous. Also the checksum is just a XOR on the ascii character sent (which is quite weak I think), this means that some of the message have the right checksum but are still corrupted (even number of bit flipped at the right position for example).

[CamilV]

I don't think the I2C signal is an issue in this case as the IMu, which is running on the same lines, doesn't lose any data, or at least we didn't notice it losing data. The signal is a bit noisy, because of the long wires and the close proximity of them, but once converted into digital, it doesn't seem to be an issue. Channel 0 is SCL and channel 1 is SDA. You can see the noisy signal here, when one line changes state, it pulls the other line with it by about 0.25V, but I don't think that's an issue, as the digital conversion looks alright and I2C only uses the 2 voltage levels, low and high. We could try having the 2 lines further apart, in that case we wouldn't have this noise, but I'm pretty certain that won't have any influence on the corrupted bits

[Nanoseb]

We've made some more test yesterday, and with i2c we can achieve only a frequency of about 0.4-0.5 Hz... Which is not enough.

Also the settings set with the weird ublox messages (done with serial) doesn't seems to survive a reboot of the gps. This would be usefull to improve the frequency rate of the gps (if we even stick with i2c which is unlikely).

[CamilV]

https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)_Public.pdf

[Nanoseb]

So today some quite good news:

• we managed to send ublox messages to the gps via i2c
• we have a script in utility (for now) to send less useless messages and increase the frequency to 5Hz
• result: we get about 3.7-4Hz in the end \o/

So we are quite happy with this and I think we can continue with i2c, just have to write the node to use that now (or adapt the current node for i2c).

PS: I just tried to test the actual rate at which GPS messages are published with a serial connection (using a rosbag and rostopic hz /position), and we have about 4.9-5Hz, so we lose a little bit here with i2c, but I think that's not too much of an issue.

[tsaoyu]

may related to this : i2c speed is related to the frequency of communication http://www.ti.com/lit/an/slva689/slva689.pdf

[Nanoseb]

I think we have this issue: http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

[Nanoseb]

Ok, yes it seems to be that, it leads to i2c hanging when the gps and the pi are out of sync, and only a reboot can help... To avoid this we can reduce the i2c baud rate (line in /boot/config.conf) but this now leads to timeout when sending/receiving messages. So we need to figure out how to increase the i2c timeout. It seems doable, but this: https://raspihats.com/i2c-hat/2016/02/16/raspberry-pi-i2c-clock-stretch-timeout.html doesn't work apparently (probably out of date).

[CamilV]

yeah, might be as there are some clock pulses that don't seem to as long as the others, like the spikes described in that article

[Nanoseb]

Some news about this, by setting the i2c frequency on the raspberry pi from 100kHz to 400kHz we don't have any issue any more:

• position message at 5Hz
• all messages pass the checksum fine!

So no clock stretching any more. Still a bit more tests to see how reliable it is (by let it run for a couple of hours), but everything seems to be all right now.

Also ublox provides a windows software (called u-center) to visualise messages in a GUI. The software works fine with wine without any configuration. To connect to the gps network can be used:

• on the laptop set u-center to connect to tcp://192.168.12.1:9800
• on the pi launch: nc -l 9800 < /dev/serial0 > /dev/serial0

This still needs to be properly documented in the wiki though.

[Nanoseb]

we tried it, and it works fine!!!