Ultimate GPS -> Teesny3.1 -> wifi broadcast

[JohnDavis]

Hi,
I am planning on the following project;
1) Receive NMEA string from Adafruit Ultimate GPS via serial1 pin0 RX pin.
2) Ammend NMEA string in teensy3.1 code.
3) Broadcast NMEA though wifi (maybe XBEE).

This project wouldn't be so bad but I am trying to utilise DMA as I should be able to utilise the 4 available channels.

I have Java and C code experience and have used teensy3.1 for various smaller projects.
But, programming with DMA I am not that confident with.

Is there a basic 'mudmap' that can assist in this cause on the process such as flag requests, interrupts etc. that could greatly assist.
I have MATLAB reading the NMEA strings using Serial.println() etc but this process is too slow, hance the DMA requirements.

Thanks.

 

[MichaelMeissner]

A naive question might be are you trying to optimize the wrong thing? Note, I have not used the ultimate GPS, but I often times see people prematurely optimizing the wrong thing. Perhaps I am completely off-base, perhaps not.

Since the Ultimate GPS is a serial device, you are limited by the baud rate that the ultimate GPS can deliver. Yes, you can increase the baud rate, but perhaps it won't be enough. And if you increase it, you likely need hardware flow control (which just went in, but I don't know if the GPS side supports it).

Once you have the data on the Teensy, then you have to do whatever processing of the data. Is this processing done using floating point? If so, note that FP is done completely in software on the Teensy, and perhaps your data processing is just too complex for the Teensy to complete in the time period. If it is just on the edge, you can experiment with using a higher clock frequency or using -O3 optimization instead of -Os.

You then have the output, which depending on the device might be another choke-hold.

Finally check on how you are reading the data with MATLAB, perhaps you are using the wrong mode to do the reading, and it is blocking waiting for more data.

Yes, DMA can be helpful for speeding up I/O, but you need to make sure that the slowdown you are attempting to fix, is really due to not using DMA, vs. looking at the rest of the code.

 

[PaulStoffregen]

I have MATLAB reading the NMEA strings using Serial.println() etc but this process is too slow, hance the DMA requirements.

Serial (not Serial1, Serial2, Serial3) to USB already does use DMA.

I don't know why it's too slow for you, but I can tell you with good confidence the inefficiency almost certainly is *not* in the Serial code on Teensy!

 

[Frank B]

Hi,
I am planning on the following project;
1) Receive NMEA string from Adafruit Ultimate GPS via serial1 pin0 RX pin.
2) Ammend NMEA string in teensy3.1 code.
3) Broadcast NMEA though wifi (maybe XBEE).

This project wouldn't be so bad but I am trying to utilise DMA as I should be able to utilise the 4 available channels.

I have Java and C code experience and have used teensy3.1 for various smaller projects.
But, programming with DMA I am not that confident with.

Is there a basic 'mudmap' that can assist in this cause on the process such as flag requests, interrupts etc. that could greatly assist.
I have MATLAB reading the NMEA strings using Serial.println() etc but this process is too slow, hance the DMA requirements.

Thanks.

I suspect, you're under-estimating the speed of the Teensy 3.x
Perhaps your problem is, that the NMEA-data are comming too slow ? DMA will not help you, in this case..

 

[JohnDavis]

Thanks everyone for your replies so far.
After some more consideration, the rate that NMEA strings are being received by the teensy should be adequate for this project.
The rate that the tracked object moves by is less than 5km/hr, approx. 1.4m/s max.
Currently the GPS module updates every 1 second so at max speed I will be less than 1 metre before the next update, with the option of upping to 10Hz if needed.

So, Q1)

I have attached some previous code which made the data transfer from teensy3.1 over USB to MATLAB almost instantaneous.
I had a 'uint16' int type and split it into upper and lower bytes. Using Serial.write I was able to separately write both bytes and then typecast back to uint16 in MATLAB.
The reason this worked is because I knew the size of the 'uint16', therefore knowing how many bytes to transfer/read.
If I am transferring a NMEA 'string' the byte size is not always known depending on parameters chosen lat/lon/alt etc.. and their own type (uint16, double) etc.
How can I split this string into the required number of bytes and transfer as before, then repacking at the other end.
Or, will I need to transfer each parameter separately, therefore knowing the exact size due to their own type castings?

Q2)
The purpose is to ammend the NMEA data being recieved and wrap into a packet that can hopefully 'inject' into a network.
I am looking at the ESP8266 module in conjunction with the following code:
https://github.com/stickytruth/esp8266-injection-example.
Is anyone aware of this concept working or at least causing the 'victim' to at least de-authenticate from the network.
Just has to be long enough so that multiple vehicles communicating their GPS position via wifi either lose communication or at least position becomes unreliable.

Hopefully my intentions are clear enough now as I think the project could be quite interesting.

 

[LenSamuelson]

I've been playing with the Ultimate GPS connected to a Teensy3.0, and found that the combination works very well. The GlobalTop GPS docs include some device-specific NMEA command sentences that I've used to set its communication speed and the selection of sentences to report. There are commands to set the update rate too, though I have not tried them and cannot comment on them.

Set 115200 bitrate:

         sniprintf(outbuffer, sizeof(outbuffer), "$PMTK251,115200*1F\r\n");
         sport.write(outbuffer);

Select only GPRMC:

         sniprintf(outbuffer, sizeof(outbuffer), "$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n");
         sport.write(outbuffer);

I've set the Teensy to 24 MHz clock (because I can...), and have never seen a problem with the 115200 speed. This combination works very well as a source of clock discipline for my (otherwise crummy) clock, generally keeping the PC within about 200 uSec of apparent PPS. The only excursions are when the PC performs operations that cause a large step function in clock rate (probably due to power supply and temperature variation), whereupon the clock discipline control loop takes a while to realign...