The UartPlug class which was recently implemented used per-byte access via I2C to retrieve each received character.
This isn’t terribly efficient, since it requires sending several bytes back and forth for each received character: first we address the UART to check its status, then we access it again to get one character from the FIFO. That’s six bytes of data for each received character.
It didn’t work well enough at 38400 baud, so I added a small buffer as optimization. The UartClass API hasn’t changed. The code which does this is:
Nothing fancy, just a small buffer (10 bytes currently) to speed things up. The essence is that when lots of data is coming in, we get 10 bytes at a time, for a total I2C overhead of 15 bytes. That’s a 4-fold reduction in bandwidth.
The setup I’m experimenting with is this FV-M8 GPS receiver:
The hookup looks daunting, but that’s because the connector is a bit small so I made a little breakout board for it:
Here’s some sample output:
The “gpsdemo” sketch is simply a serial pass-through, converting 38400 baud to 57600 along the way:
But it still loses character along the way, as seen in this snippet:
The RMC line has a partial line at the end, after the “*7B” checksum.
My guess is that this isn’t the UARTs fault, nor the I2C bus. What seems to be happening is that the Serial class does not buffer its output, so all output causes the sketch to become unresponsive for input. In theory the 57600 baud link should be able to get data out fast enough, but I suspect that in practice there is an occasional hickup.
If this is indeed the cause, then it’s another example of how wasting time can lead to problems.
Back to the GPS. After a few minutes it finds its position in 3D. The following info comes in 5 x per second:
Some additional details are reported once a second:
(ignore the last few garbled lines, I really need to lower that baud rate a bit)
Here’s an even more accurate fix I found in the data stream:
$GPGSA,A,3,12,22,09,28,18,26,17,27,,,,,1.32,1.02,0.85*02
So that’s up to 8 satellites – indoors, with stone/concrete walls and coated double-glazing windows. Impressive… older units I tried never even got a fix indoors!
To interpret this GPS data, check out Mikal Hart’s TinyGPS library, it can easily be hooked up to the UART plug – just use this code at the top of his test_with_gps example:
… and init nss to match the baud rate of your GPS unit.