USB-to-PC output position not sending data just after connecting the cable

My ReachView version is: v2.7.3-r0 on Reach RS
OS: Ubuntu 14.04 on Dell precision M3800 laptop.

I using USB-to-PC position output in NMEA format, and I have found a strange and unwanted behavior after plugging the cable, as no data is received. This are the steps to reproduce:

  1. Enable USB-to-PC position output at ReachView
  2. Plug the USB cable to the computer
  3. If i run cat /dev/ttyACM0 nothing is seen. It keeps there waiting for data.
  4. If I change baud rate at ReachView and apply it, the cat I was running is closed (which is Ok). But if I run again cat /dev/ttyACM0 I can see the data flowing.

What I would have expected/wanted is starting to get data just after plugging the cable. That is important when Reach RS is used with daemons like gpsd, as it is not enough to plug the unit to the USB. Also manual change of the baud rate or enable/disable on position output configuration is needed it you want to get data.

Regards,
Iván

1 Like

Ok ! I and two other Germany’s users can also confirm that there is a problem.

When I connect usb to my tablet with autosteer software (cerea) I don’t get data.
If I change some reach rtk settings and restart Rtklib on reach data flows again.

I did nothing had the time to investigate the problem if it’s a reach or problem of my software - so thanks to Ivan !!!

I have also noticed another problem with position output by USB. I have been experiencing disconnections, so data stops to flow through USB port. When happening I usually have to change baud rate or something so that position output is restarted… but it usually restart in a different tty. For example, it was maybe sending data through /dev/ttyACM0 but after changing baud rate to restart data is sent through /dev/ttyACM1.

Any ETA on when this issues could be checked? I really need a solution for that as soon as possible.

Regards,
Iván

Hey Ivan,

Sorry for taking so long. I can’t really recreate this behavior. If you are using screen from your PC side to read the tty, does the problem persist?

Hi Efedorov,

The problem persist if I use screen. It keeps there waiting for data but nothing is sent… until I change something in position output (for example baud rate). After that, data starts to flow properly.

@egor.fedorov I have also tried in another computer. The behavior is the same. Are you not able to reproduce it? It happens always in my case: just unplug the USB, and plug it again and no data at tty.

OS version and kernel is the same, but laptop this time is a Sony Vaio VPCSA3C5E

Ok, after some some more attempts, I finally saw what you are talking about. Definitely a weird issue. I’ll look around some more and come back here with my findings.

Ok, I can confirm I see the problem. It is very low-level, but should be fixable from RTKLIB side. You can expect a fix for this next week.

1 Like

Nice @egor.fedorov, many thanks!

Not sure if related (as I had some USB troubles on my laptop), but I has been experiencing random disconnections. Do you know if this found bug could be related with that?

Regards,
Iván

Nice @egor.fedorov, many thanks!

Not sure if related (as I had some USB troubles on my laptop), but I has been experiencing random disconnections. Do you know if this found bug could be related with that?

Regards,
Iván

I don’t think so. The problem I’ve found is connected to USB-serial connection not reinitializing properly after replugging the wire.

I suggest you try a different cable or USB port.

Hi @egor.fedorov,

Any estimation on when that fix will be released? It is important for my use case.

Regards!
Iván

Currently working on this, should be released tomorrow or early next week.

Nice. Thanks!

Hi…i am a new user here. In my case when I connect usb to my tablet with autosteer software. I don’t get data.If I change some reach rtk settings and restart Rtklib on reach data flows again.

pcb assembly usa

Hi @egor.fedorov,

Does the just releases ReachView 2.8.0 include a bug fix for that issue?

Regards,
Iván

1 Like

Hi,

I wish I could include that, but the problem turned out to be a little more complicated than I anticipated. The fix is still in the works, I’ll update you ASAP.

I’ve got the PR ready, so the next release will contain the fix. Currently in the testing stage.

Fixed here.

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