Emlid NMEA to TSIP Converter

Hello still trying to get Emlid to connect to everything.

I am really trying to get Emlid to be an easy solution for precision agriculture. RTK is indispensable in many farming applications requiring ground coverage efficiency. The #1 brand of all in this regard is Trimble and there Ez line of aftermarket auto guidance steering systems. After the original Trimble 150 they closed the window tight on using NMEA for guidance. Though as we have seen in my previous post Emlid M2 to Trimble Ez Guide 150 Success that this is only a software limitation.

Online as everyone has searched there is a NMEA to TSIP converter on Github. I thought this would be a good place to start so i built it to test. Looks like some nice Russian University student(s) almost made it. I will give them the benefit of the doubt and say it may have worked in their specific case but it does not in its current form work in any way with an Emlid or my TSIP guidance system. Also looking through the documents it looked as they just kind of abandoned it mid way.

After much time on google translate and programming forums (Canola is getting to tough to Combine at 10pm now) I was able to build the hardware and burn the software into the Nano.


Here is the hardware setup as directed by the C++ code. I glued everything onto a Samsung SDD CD to make it look a little more commercial and keep the components stationary.


Trimbles TSIP SDK came with a great little Parser program for viewing outputs I highly recommend. It is as easy as NMEA router but it gets all the sentences. I found that the EMLID is dumping out 1527bytes of data per cycle. This exceeds the buffer size by tons in the converter program I think this is a great place to start to determine why it does not work. The Converter is also looking for only Three NMEA sentences… Need for sentence selection in the EMLID yet again. Also it is looking for GP talker code… Need for talker code selection again.

My first step to make this work will be to completely retool the front end of the converter so it can handle sorting sentences like the Shipmodul, then completely ignoring talker codes only recognizing sentences. Also I have not done it yet, but I have to calculate if it is even possible for the Nano to take the 1527byte input at 10Hz. It may need different hardware all together.


So here we see that the converter can spit out some unpopulated Junk TSIP that a Trimble should understand. So far my Ez Guide ignores this data completely, I think due to mismatched port settings more research required.

So do I think this project is possible, for sure! But it will take some time as I am both new to C# and Arduino but learning quickly. I have programmed industrial PLC and HMI before but ladder logic is truly logical. It will be a fun winter this winter, lots of learning to do.

4 Likes

True That

5 Likes

You guys really know how to roll in style :cowboy_hat_face:

Awesome pictures!

With that many you would cover about 180acres an hour easy, wow!

1 Like

I guess we’re complementary then… I’m used to C#/C++/etc. I’ve read some ladders in the past, but don’t ask me to write them. I even prefer logic circuits above ladder. I think it depends on the kind/size of problem, and previous experience…

Which part is in C#? did you mean C++? I never used the arduino hardware (I’m using esp most of the time, because of the integrated wifi-capabilities), anyway, programming them can be done in the same way, and with the same software.
I think processing power shouldn’t be a problem for parsing, especially when you can ignore a lot of stuff… but there’s all the conversion stuff as well… I don’t how how complex TSIP is (or the conversion to TSIP), should study some docs/specs for this…
Either way, make sure the serial bandwith is configured big enough, the typical 115200 isn’t enough for 1527bytes@10Hz. (Maybe the esp can help out here because you then can use IP between reach/esp - which has a lot higher bandwith and doesn’t require wires to the receiver)
Also since you won’t have a power-limitation in this application, you could even use some kind of single-board computer (i.e. Raspberry pi, …) and you’ll have plenty of processing power. (you’ll be moving farther away from the PLC/electrical world, but it’ll be easier to develop C/C+±style applications because you’re less constrained by resources and hardware specific issues. After all the purpose of your device is doing data-processing/conversion and not really ‘controlling’)
Actually I think that would be a much better architecture for AgOpenGPS as well, all control software running somewhere on the controlled devices itself, and the user interface could then be hosted from an included webserver, and used/viewed with a tablet smartphone/tablet of choice.

Also my advice would be to develop the core-conversion-code completely on desktop, with data from input-files (or even hardcoded input). It’ll be easier to test with various input-data scenario’s.
Even when using arduino, the C/C++ developed on desktop will be pretty easy to integrate.

And since we’re doing some non-emlid project share…
Some years ago, I did another project for creation of orchards (tree and pole holes in a single pass) (video), and the guy working on the hydraulics/pneumatics/mechanics also had to switch from ladder to logic (because of limitations of the PLC he used).
I only did the field modeling-software and position-tracking to send triggers for start/stop motion/drilling.

1 Like

Think you are 100% right about the “what you get used to” :+1:

I got lucky today, i doubt at this point i could fully jump in from scratch on c++++ but i sure can troubleshoot and make changes regardless.

I got the fields to populate this morning, and it does not look like complete gibberish…

But plugging into my 150 set to TSIP no luck would not take it.

Then i find they built a wall within the wall to make sure you could only use certain receivers by implementing a machine code value

So after a mammoth web search i now have a roadmap of guess and check additions to the converter.

I will be modelling this converter after the output packets of an AgGps 132 and hoping for the best.

This is both a fun experiment and learning opportunity, but also infuriating knowing that I mowed my lawn all summer using NMEA for guidance. The only reason they used TSIP for guidance only on the 250 and up was to close the box to everyone permanently.

I do know in current Trimble monitors (CFX750/FMX100/TMX2050) when using AutoPilot, the TSIP baud rate is set to 115200

If there is any data on the Trimble side that I can help you with, let me know. I would be happy to research and send if I can find it.

I would love to help but haven’t messed with any of the coding since the 80’s and haven’t touched a raspberry pi or nano that you are using.

I really just wish I could see the data out of TSIP reciever.

My only Trimble other than the 150 is too new and does not have TSIP as an option.

The 150 Is able to use a TSIP receiver. I put its data port connection through Trimbles parser program and it is sending some kind of handshake out but i cannot discern what it contains. It only says NMEA checksum error. At the very bottom of the selection screen it asks for the GGA precision? GGA That’s NMEA? Does it want NMEA but in binary?

After much research the connection for this device for TSIP is 9600:8:ODD:1

So this picture is from the manual, its says it will auto negotiate comm speed and NMEA Messages?
So GGA, VTG, SLA, RMC??? but does this switch them back to ASCII from binary or wraps them up and sends them binary? So many questions.

So in one breath it is saying it needs VTG, in the next it is not. So Tsip just giving GGA is good enough, but straight NMEA messages need VTG? Why the difference?

I was coming strong out of the gate but now it looks like the first few steps of a Marathon.

When time permits, I will record some TSIP data for you.

Thank you, whenever you can get it, that would be most helpful. I can play with this converter all winter i am not in a huge rush.

But I have this feeling that TSIP conversion will not work as a one for all converter. It will have to be tailored to the individual situation. I could be wrong but the TSIP manual hints otherwise.

But I have to say the more I dig into this project the more I am liking Raven Guidance and TeeJet.

I think the best option now is definitely AgOpenGPS by far. Due to the ability to change or create anything.

I am willing to make big changes just to use Emlid RTK. Emlid works extremely well, and has more uses than collecting dust on top of the cab.

I think my next move is to look in the .cpp file for the TSIP parser and see what messages it can spit out. Then try to create them. Hopefully it will show the structure of the Binary GGA message.

The TSIP project will be nice if it works with all Trimble monitors. If it is individual, it will not be feasable.

Getting the 1008 message in the base output, is a works with all.

Well this is as Bipolar a project as one could imagine. It goes from hopelessness to finding another clue to drag it on.

Here are the recordings of the laptop sending commands to the internal GPS receiver of the 150. Its easy to see the converter spits out Zero of the Messages the internal GPS or the computer does. Also the converter may have to work smarter by only outputting messages if requested.

Some of the messages are not covered or possibly invented in the 1999 TSIP manual so will have to record their raw data and just spit that back out to see if it makes a difference.

After the world wars humanity learned that standardization of products and protocols saved lives and resources. I have this horrible feeling if we go to Mars there will be a proprietary proprietary MNSS communication standard glitch that will cause the potato harvest to fail causing starvation at the colony. Even though they have 12 NMEA rovers at hand.

The converter does send Data I am just not convinced its to the right places.

Ok small update

I finally got to snoop the 250 being used as external receiver to the 150 for guidance.

What i know for sure is the the Arduino nano is too slow to pull this off, after the initial handshake at 9600 the units ramp up too 115200baud. This is outside of the limits if the Nanos 57600baud max.

This is also wild cause you can only manually set the 150 to 38400baud.

Also after recording the traffic in both directions almost none of the messages used in the existing converter are required or used.

My hopefulness that it used GGA at the agreed on speed was wrong. It seems to send all the satellite data in raw format to the 150. How much is really needed to function is to be discovered.

There is also a definite call and reply to the messages. I am unsure if flooding the guidance system with the needed messages out of sync will suffice. The converter will most likely have to be smarter than just a one way dump.

It looks as though the workflow will have to sort data from the NMEA, put it in registers in tsip in converted form, ready to be sent for when it is called upon by guidance.

Also you would have to never update your guidance firmware cause one new tsip command change could mess it up.

This still seems possible and a fun challenge, but its making AgOpenGps, the original 150 and Teejet look so much better in price and value and longevity.

3 Likes

After reading for many days on the amtel AVR forums I was pointed in the right direction of a workaround for the 16mhz 115200 baud issue. Which involved a ton of guess and check to work. But got confirmation of success from the tsip parser on the computer. There is a hardware clash between the clock speed of the processor and this baud rate.

Been sniffing 250 to 150 comms and reading more into the TSIP standard. The above setup is what I am using now to simultaneously send to the 150 and view messages on the PC

A glimmer of hope the Diff Status value populates on the 150 from the converter. Also searching sats pops up, no more “no gps comms”

Now my biggest question is if I can just throw the TSIP replies at the wall and see if they stick, or if they have to exactly arrive after being commanded. Also noticed the replies out of the converter are shy by one byte vs the 250s messages.

I also ordered a Nano Every that runs at 20mhz just to make sure the Arduino is not clashing clock and comms. But the diff status has me reinvigorated.

Hopefully next project update the guidance will know where it is in the world!

2 Likes

Big News!!!

I got some new serial logging software, and it has revealed to me that the 250 is sending $GPGGA and $GPVTG and they are contained within the RTCM generic TSIP wrapper so you do not see it!

I have also moved away from the current TSIP converter on github, as it is difficult to alter without breaking.

Currently writing new simpler code. Already can select sentences, and change talker codes, but now its a matter of timing their exit.

Then to put it inside the RTCM wrapper.

Now its just the question if gga vtg is enough or what other messages are truly needed.

4 Likes

The other two most common messages are GSA and RMC. Not sure if they are needed but most Ag systems utilize them

1 Like

If the code for sentence filtering works after i get it timed correctly at 5Hz it will be easy to pick sentences and switch talker codes. GSA and RMC just have to be named in the code and they pop out.

That will put me at the same place as the Shipmodul.

I think in the long run I may use dip switches to turn on and off sentences, also one switch to select 5 or 10 Hz. And one TSIP or NMEA. Also more blinky LED’s you can never have enough.

The step after will be the TSIP conversion, and possibly some hardware signature emulation.

I still am seeing some limitation with the current 328p 16mhz knock off NANO. The genuine 20mhz NANO Every comes in today. Hopefully give this project some more HP.

3 Likes

What’s the name of the new serial logging software you have ? You remind me of myself back in the 80’s trying to create a demodulator of the WWV and WWVB radio time signals that are broadcast on 2.5, 5, 10, 15 and 20 MHz. I wanted to have precise time for astronomic observations. I eventually succeeded and had the time signals info set my HP48GX system time, which I had wrote software logging horizontal/vertical angles with precise time stamps.

I can’t remember the software name I used, but it was DOS based and used the RS232 serial port to determine which HP48GX “machine language” commands to set the time. I was so proud of myself when I accomplished what I set out to do, so I can relate to what you have accomplished.

1 Like

I am using a program called ioNinja. It can also replay the timestamped logs out the computers serial port.

Well i cant figure out whats up with the new NANO Every boards, but i am in good company lots online are having issues with them.

Still hammering away with the original Nano, I can get it to output the sentences looking right. But the Hz rate slows way down.

I am guessing due to my couple months of nighttime C language study are to blame.

1 Like

I have working code for the same function as the shipmodul, with the same issues of the ship modul. The Nano code selects GNVTG and GNGGA, changes the talker code, recalculates the checksum, and spits it out the finished product readable by the Trimble150. But now having Hz issues.

The Emlid M2 spits out 12 sentences, 684Bytes, that’s 5472 bits per cycle, 5hz is 27,360bps. Confirmed that bare minimum speed to get it across is 38400bps. The fastest speed Software Serial will do without errors is 38400.

The faster you can get the data in the faster you can process it and get it out. I need the hardware serial to eventually go to 115200 for output after the frames are coded for TSIP. Also the ability to maintain different baud rates. I tested and both the Nano and Nano Every. They can maintain 5hz GP’NMEA after being fed a stream of only two GNXXX sentences.

ioNinja helped me greatly in troubleshooting the serial streams. I was about to scream until Noticing that changing “N” to “P” changes the XOR checksum. Then the fun of figuring out how to calculate it.

In my short time as a hobby C programmer I have learned four things;
1 Very few people or sites online really explain the implementation of any commands and coding well
2 Most of the helpful responses and posted code do not actually work
3 There is always rude dudes telling you how wrong your code implementation is, but offer no
tutorial or further explanation on their chosen better method.
4 Old programmers will either give you a useless suggestion that only would work on punch cards or a TANDY, or will drop you massive experience gems so valuable that it propels you forward in very little time.

So the short story is i have ordered an Arduino DUE, 4X the processor speed, and 4 hardware UARTS, PLUS CANBUS! I need more Horsepower!

3 Likes