Reach Module TCP output format

Reach Module / M+ / M2 Getting started
1

Dear all,

I’ve recognized, that the standard deviations of the TCP output might be inconsistent with what is displayed in the web interface.

As I see, the order in the webinterface is sdn, sde, sdu as shown below.

Unbenannt.PNG
Unbenannt.PNG1920×1096 92.4 KB

I’m pretty sure I did not confuse the order. I do handle the incoming stream with the following python code:

def Emlid_line2dict(self, raw_data):
      ENU_keys = ['timestamp', 'E', 'N', 'U', 'quality', 'satellites', 'sdn', 'sde', 'sdu', 'sdne', 'sdeu', 'sdun', 'age', 'ratio']
      
      data = raw_data.decode('utf-8').strip()
      values = data.split()
      #print(f'{values[0]} {values[1]}')
      timestring = values[0].replace('/', '-') + ' ' + values[1]
      
      del values[1] # Deletes second entry time
      values[0] = timestring # Replaces firt entry date with timestring

      raw_data_dict = {key: value for key, value in zip(ENU_keys, values)}

      return raw_data_dict

Incoming lines are added to a dictionary with the keys defined in “ENU_keys” and then forwarded correspondigly to the subsequent measurement system.

Is there anything I might miss? All the other values seem to be in the correct order.

I read that sdne, sdeu, and sdun are not transferred by the Reach Module. Is that correct? Any chance to get to those values?

Thanks for your support

Johannes

3

Hi Johannes,

There might be a slight delay before you receive the stream data to your end device.

We output the standard deviations in the following order: sde, sdn, sdu.

The sdne, sdeu, or sdun aren’t transmitted from the receiver.

5

Dear Liudmila,

many thanks for your reply. Sorry if I was not precise enough to explain what I was concerned about.

Yes, there is a slight delay in transmission which is totally fine for me. I was more focused on the general magnitude of values. I try to make it clear by directly linking the three values with each other. It seems that they match in the following order:

  • 1st value (lat) of webinterface might match with 3rd value in serial stream (ENU)
  • 2nd value (lon) of webinterface might match with 1st value in serial stream (ENU)
  • 3rd value (height) of webinterface might match with 2nd value in serial stream (ENU)

So it seems that the transferred stream hast the following order of standard deviation:

lon - height - lat

or

E - U - N

Can you confirm this behaviour?

Best regards

Johannes

6

Hi Johannes,

Thanks for the details!

We checked the position stream from the Reach Module on Reach Firmware 28.4 using ENU format and the coordinates are transmitted in the following order: +eeeeeeeee.eeee +nnnnnnnnn.nnnn +uuuuuuuuu.uuuu. It’s hard to say why you receive the coordinates in somewhat reverse order.

7

I completely agree with you. Coordinate transmission is as you mentioned. I am referring to the standard deviation (sd) that is transmitted aright after quality flag and number of satellites.

8

Hi Johannes,

I see that your readings have the sde, sdu, sdn order. However, the correct order should be sde, sdn, sdu. That’s what we confirmed with our tests using the Reach Module.

9

Dear Liudmila,

many thanks again for your response.

I do refer to RTKlib manual Appendix B where the sd output is specified in the following order:

grafik
grafik906×212 12 KB

I may need to also mention hard and software I am using. We are talking about the old version with the current software 28.4.

I’d like to try to visualize this once again using a screenshot.

grafik
grafik1920×1293 102 KB

Here you might observe that the values I write into my measurement system correspond to specific values we see in the web interface. I pointed with arrows to the channels they correspond to and named the values in my measurement system correspondingly in purple. The order you see them is the order I recieve them in the stream.

It is clearly visible that the second value I receive corresponds to sdu which should not be the case.

So the order I am receiving the sd values seem to be “sdn sdu sde” and not what is specified in the RTKlib and also not what you mentioned before.

I am a bit confused about this and need to figure out where the error lies. (Hopefully not in my code :slight_smile: )

Best wishes

Johannes

10

Hi Johannes,

Could you please check the stream that comes from Reach via TCP directly and compare it the same way with the values in Reach Panel? You can use the netcat tool for this, for example. It’d be great if you shared the screenshot of the stream and values in the interface as well.

Thank you!

11

Hi Liudmila,

I used a python script that simply reads one line and plotted the lines into the terminal. Indeed the webinterface shows slightly different values. At least due to the performance of the Raspberry Pi I used.

image
image1552×806 216 KB

The order seems like I colored the values: “sdn sdu sde”

Could this be related to the firmware? Can you run your test again making sure you use 28.4 on an old module as well?

Best wishes

Johannes

12

Hi Johannes,

Thanks for your notes!

We’ve double-checked the ENU stream from the Reach Module on version 28.4. Indeed, the sequence for the standard deviation is different from the one that is mentioned in the RTKLib manual. It’s sdn, sdu, sde. I believe if you just change the values in your code it should work fine. Or you can also use the LLH format, it has the order as in the manual.

1 Like
13

Dear Liudmila,

many thanks for checking this and confirming the behaviour.

I do not have any problem changing the order of values.

I’m happy that this issue is herewith solved.

For anyone that questions the same issue, I would like to quickly summarize the outcome:

At least for the TCP output of the Emlid Reach Module (tested with firmware version 28.4) in the ENU format transmits the standard deviation in the following order:

sdn, sdu, sde

This does not comply with the RTKlib manual or the webinterface. Please keep that in mind.

1 Like
15

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.