RTK using Reach , navio2 and Reach RS+


(Dhruv Patel) #1

I have a Reach RTK GNSS receiver (Rover GPS), a reach RS+(base GPS).
I have a Navio2 and a raspberry pi.
Question 1: Is it possible to just use Navio2 and Reach RS+ to do RTK (Antenna connected to Navio2 GNSS), without using Reach GNSS receiver. Because
Question2: Is it possible to use R-pi and Reach GNSS(INTEL EDISON) without NAVIO2 to do RTK. I connected the reach RTK and Reach RS+ , using Reachview on the same network and i’m able to get the corrected location on the Reachview app. So when I set the "position output’ setting for Reach RTK GNSS module (which is connected to R-pi using Micro-USB to USB cable) on The Reachview app and read it using screen ,would that data be the corrected position after(RTK) or would I need to use rtklib for post processing for including it in a separate navigation algorithm(not using mission planner) .


(Gleb Gira) #3

Hi @dhruv1226patel,

Unfortunately, it’s not possible to set RTK with Navio2 and Reach RS+/original Reach only.

You can set up original Reach to get base corrections from Reach RS+ and then output corrected data on Navio2 in RTK mode.

Detailed integration guide can be found in our docs.


(Dhruv Patel) #4

Using the docs I tried to connect the Reach GNSS to a Raspberry pi.
I’m getting the corrected the positions on my mobile web brower. I then set the Position output as USB to PC—> baud rate 115200–Format -NEMA in the reachview app for the Reach GNSS receiver.
It shows that it is connected to
/dev/ttyGS0

The r-pi shows the following device connected but no serial port. ??
I tried
screen /dev/ttyUSB0 , screen /dev/ttyACM0 , screen /dev/ttyGS0
all terminate , no incoming data string
What to do?
snip


#5

In your screenshot above, was Reach booted up? It shows as disconnected at 03:54:32 which is 1 second after it was recognized.


(Dhruv Patel) #6

it was booted up. I checked again and it is showing the same.
While i connect it with any device it connects and disconnect twice and after that stays disconnected.
I also tried reflashing the firmware for Reach but the problem still persists


#7

Maybe there is no driver or no udev rule that recognizes your Reach.

Do you have a USB powered hub? Can you try to put that inbetween Navio2 and Reach? See if it makes any difference.

Here is what happens in the system log when I plug a Reach into a Linux computer:

Jun 15 17:38:26 Linux_computer kernel: [6040289.628748] usb 4-5: new high-speed USB device number 11 using ehci-pci
Jun 15 17:38:26 Linux_computer kernel: [6040289.797987] usb 4-5: New USB device found, idVendor=8086, idProduct=e005, bcdDevice= 0.a0
Jun 15 17:38:26 Linux_computer kernel: [6040289.797991] usb 4-5: New USB device strings: Mfr=2, Product=1, SerialNumber=3
Jun 15 17:38:26 Linux_computer kernel: [6040289.797993] usb 4-5: Product: MERRIFIELD
Jun 15 17:38:26 Linux_computer kernel: [6040289.797994] usb 4-5: Manufacturer: INTEL
Jun 15 17:38:26 Linux_computer kernel: [6040289.797996] usb 4-5: SerialNumber:
Jun 15 17:38:26 Linux_computer mtp-probe: checking bus 4, device 11: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:38:26 Linux_computer mtp-probe: bus: 4, device: 11 was not an MTP device
Jun 15 17:38:26 Linux_computer mtp-probe: checking bus 4, device 11: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:38:26 Linux_computer mtp-probe: bus: 4, device: 11 was not an MTP device
Jun 15 17:38:35 Linux_computer kernel: [6040298.706716] usb 4-5: USB disconnect, device number 11
Jun 15 17:38:36 Linux_computer kernel: [6040299.640803] usb 4-5: new high-speed USB device number 12 using ehci-pci
Jun 15 17:38:36 Linux_computer kernel: [6040299.810147] usb 4-5: New USB device found, idVendor=8086, idProduct=e005, bcdDevice= 0.a0
Jun 15 17:38:36 Linux_computer kernel: [6040299.810153] usb 4-5: New USB device strings: Mfr=2, Product=1, SerialNumber=3
Jun 15 17:38:36 Linux_computer kernel: [6040299.810156] usb 4-5: Product: MERRIFIELD
Jun 15 17:38:36 Linux_computer kernel: [6040299.810159] usb 4-5: Manufacturer: INTEL
Jun 15 17:38:36 Linux_computer kernel: [6040299.810162] usb 4-5: SerialNumber:
Jun 15 17:38:36 Linux_computer kernel: [6040299.816461] usb 4-5: USB disconnect, device number 12
Jun 15 17:38:36 Linux_computer mtp-probe: checking bus 4, device 12: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:38:36 Linux_computer mtp-probe: bus: 4, device: 12 was not an MTP device
Jun 15 17:38:39 Linux_computer kernel: [6040302.680899] usb 4-5: new high-speed USB device number 13 using ehci-pci
Jun 15 17:38:39 Linux_computer kernel: [6040302.837720] usb 4-5: New USB device found, idVendor=8087, idProduct=0a99, bcdDevice=99.99
Jun 15 17:38:39 Linux_computer kernel: [6040302.837725] usb 4-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 15 17:38:39 Linux_computer kernel: [6040302.837727] usb 4-5: Product: USB download gadget
Jun 15 17:38:39 Linux_computer kernel: [6040302.837730] usb 4-5: Manufacturer: Intel
Jun 15 17:38:39 Linux_computer mtp-probe: checking bus 4, device 13: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:38:39 Linux_computer mtp-probe: bus: 4, device: 13 was not an MTP device
Jun 15 17:38:39 Linux_computer mtp-probe: checking bus 4, device 13: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:38:39 Linux_computer mtp-probe: bus: 4, device: 13 was not an MTP device
Jun 15 17:38:42 Linux_computer kernel: [6040305.312550] usb 4-5: USB disconnect, device number 13
Jun 15 17:39:00 Linux_computer kernel: [6040323.453169] usb 4-5: new high-speed USB device number 14 using ehci-pci
Jun 15 17:39:00 Linux_computer kernel: [6040323.610408] usb 4-5: New USB device found, idVendor=8087, idProduct=0a9e, bcdDevice= 3.10
Jun 15 17:39:00 Linux_computer kernel: [6040323.610411] usb 4-5: New USB device strings: Mfr=2, Product=3, SerialNumber=4
Jun 15 17:39:00 Linux_computer kernel: [6040323.610412] usb 4-5: Product: Edison
Jun 15 17:39:00 Linux_computer kernel: [6040323.610414] usb 4-5: Manufacturer: Intel
Jun 15 17:39:00 Linux_computer kernel: [6040323.610415] usb 4-5: SerialNumber:
Jun 15 17:39:00 Linux_computer kernel: [6040323.611898] cdc_ether 4-5:2.0 usb0: register ‘cdc_ether’ at usb-0000:00:13.2-5, CDC Ethernet Device, e6:1f:2c:6c:07:73
Jun 15 17:39:00 Linux_computer kernel: [6040323.612389] cdc_acm 4-5:2.2: ttyACM0: USB ACM device
Jun 15 17:39:00 Linux_computer kernel: [6040323.612915] usb-storage 4-5:2.4: USB Mass Storage device detected
Jun 15 17:39:00 Linux_computer kernel: [6040323.613074] scsi host8: usb-storage 4-5:2.4
Jun 15 17:39:00 Linux_computer mtp-probe: checking bus 4, device 14: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:39:00 Linux_computer mtp-probe: bus: 4, device: 14 was not an MTP device
Jun 15 17:39:00 Linux_computer systemd-udevd[28245]: Using default interface naming scheme ‘v240’.
Jun 15 17:39:00 Linux_computer systemd-udevd[28245]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jun 15 17:39:00 Linux_computer kernel: [6040323.628679] cdc_ether 4-5:2.0 enp0s19f2u5c2: renamed from usb0
Jun 15 17:39:00 Linux_computer mtp-probe: checking bus 4, device 14: “/sys/devices/pci0000:00/0000:00:13.2/usb4/4-5”
Jun 15 17:39:00 Linux_computer mtp-probe: bus: 4, device: 14 was not an MTP device
Jun 15 17:39:00 Linux_computer systemd-udevd[28253]: Using default interface naming scheme ‘v240’.
Jun 15 17:39:01 Linux_computer kernel: [6040324.621810] scsi 8:0:0:0: Direct-Access Linux File-CD Gadget 0310 PQ: 0 ANSI: 2
Jun 15 17:39:01 Linux_computer kernel: [6040324.622169] sd 8:0:0:0: Attached scsi generic sg2 type 0
Jun 15 17:39:01 Linux_computer kernel: [6040324.622771] sd 8:0:0:0: Power-on or device reset occurred
Jun 15 17:39:01 Linux_computer kernel: [6040324.624409] sd 8:0:0:0: [sdd] Attached SCSI removable disk

In the log above, you can see that three devices are picked up:

  • a network interface (usb0)
  • a serial device (/dev/ttyACM0)
  • a storage disk (/dev/sdd)

It took 34 seconds and 3 USB disconnects before the serial device was brought up (ttyACAM0) and that is the thing you are looking for.

At least it gives you something to compare to for now.


(Tatiana Andreeva) #8

Hi @dhruv1226patel,

Have you managed to resolve the issue?


(Dhruv Patel) #9

I connected the reach with r-pi using USB cable . The r-pi has the raspbian image installed provided on EMLID’s website. And below is the reach settings.


(Gleb Gira) #10

Hi @dhruv1226patel

Sorry for the delayed reply.

Please post the output of dmesg | grep -i tty command with Reach connected to Navio USB port.


(Dhruv Patel) #11

dmesg


#12

So did you try screen /dev/ttyAMA0 ?


(Gleb Gira) #13

Hi @dhruv1226patel,

Did you managed to resolve the issue?

If no, could you please run the command proposed by @bide?


(Dhruv Patel) #16

I tried the command but no incoming data.


#17

Can you confirm that the postition (long,lat) is updating on the status page at the same time you ran the command screen /dev/ttyAMA0

I don’t think it should matter for a USB-to-PC connection, but you could try adding the baud rate selected in ReachView:
screen /dev/ttyAMA0 115200

Can you confirm that the ‘screen’ program starts? Did you have to exit the program with ‘CTRL-a k’ or did it just kick you back to the terminal?

If it kicked you back to the terminal, then you need to use the sudo prefix to gain priveledges to access the port.

Please be more verbose with your answers so that we have some information to go on.


(Dhruv Patel) #18

the screen command dos not automatically terminate. I had to use the ctrl + a - k command to terminate the screen. The GPS co-ordinates are updating in the status page but still there are no incoming strings when I screen the port.


#19

OK, that is unfortunate, as I don’t know what to suggest next.

I hope @gleb.gira can provide another suggestion.


(Gleb Gira) #20

Hi @dhruv1226patel,

Could you please provide us a simple system report? Here is the tutorial on how to create it.

Also, photos of your hardware setup would help us to sort out the reason.