Please some clarification... fix/float & base status display _& ERR_CONNECTION_REFUSED

guenter · April 5, 2016, 2:21pm

Hi all,
After days of flashing to get stable Reach devices (often: ERR_CONNECTION_REFUSED on port 80) I am now somewhat confused about other, older entries in this forum concerning my next steps:
Software used: ReachView v.0.3.0 Reach image v1.2
In Rover single mode each device is ok. I do get satellites , logs and so on

Setting up one device as a base, I do not get any more Status displays on the Base-side, just everything empty in (Mode: base, Status: started) . -->Do YOU have sat. displays on the Base web page?<-- I do have to input LLH for the Base, no automatic…? as indicated in dec.2015.
I have connected 3DR-radios and the base is sending a lot of information ( I have choosen RTMC 1002), which I do receive at the Rover Input pin (RX). Checked with oscilloscope. Nothing is send back to the base (perhaps correct?) I never got a float/fix on the Rover in Mode: kinematic, Status (stays at): single
I never get grey bars.

At Base: Output Path for corr.: serial, USB (using 3DR with USB and OTG-Cable) with GPS_GLONASS_5Hz.cmd or GPS_10Hz.cmd.

At Rover: Input Source for corr.: serial UART (using 3DR with RX, TX correctly connected) with reach_kinematic_default.conf

At first I tried it as described via port 9000, but also no reaction at all.

Hopefully someone can enlighten me.
Thanks

egor.fedorov · April 5, 2016, 3:02pm

Hi!

Base mode does not provide satellite levels, as well as automatic position, I’ve updated the docs to reflect that more clearly.

Regarding RTCM3 messages, you should start with all of them. At least 1002 and 1006 are required to transmit GPS L1 obsercations and base station coordinates.

That’s ok.

If your corrections are coming through, you should see the grey bars. When using radios, check the baud rates are the same on both sides.

Also screenshots of settings on both sides will help!

guenter · April 5, 2016, 3:45pm

Hi Egor,
thanks for your fast reply.
First to the 3DR: They are identical:

Now the Base and Rover Settings:
Base:

Rover:

Thanks for clarification on the “empty” Base mode page.

egor.fedorov · April 5, 2016, 3:57pm

No need for the advanced config

As a debug measure, could you try changing the baud rates to 115200?

guenter · April 5, 2016, 7:28pm

Well, what should I say…

It works!

I defined both 3DR radios with 115200 Baud AND changed the Rover serial UART speed to 115200. Thats all I did.

So, the base is sending with 115200 Baud via the USB-OTG!
3DR-settings:

Rover:

Thanks a lot

guenter · April 6, 2016, 9:46am

…might remain the question. Where is the fix?

igor.vereninov · April 6, 2016, 11:14am

If you are using stock antennas they require a ground plane to work properly. 200mm diameter metal sheet will do.

guenter · April 6, 2016, 3:10pm

I do have these ground planes. … but now I am stuck again with ERR_CONNECTION on port 80 on my base.
Thats it!

panky · April 7, 2016, 9:15am

Hi Günter;
1.check if reach is connected to WiFi (use something like fing) (reach IP:port 5000 should be reachable if connected to WiFi)
->if not: check for wifi hotspot of reach
2.check if reach-view is started (led on the reach blinking as described in the Docs)
If not: power on and off
3. try to avoid that the logs fill up the whole disk-space -> delete logs (i believe emlid is working on that issue) if you can’t reach the reachview-app you can delete Logs over ssh in /home/reach/logs

guenter · April 7, 2016, 9:28am

Hi Benedict,
There is no way to re-activate a dead port 80. At least, up to now, the only way is to reflash and update the Intel Edison.

If port 80 is dead, I can reach the device via SSH, that is not the problem, but all http-ports refuse connection.
That is : the “normal” port of the WiFi entry AND the port 192.168.2.15 via direct USB NDIS connection.
I have deleted all the logs.
…possibly there is a way to reset/restart the web-engine via ssh, but I have no further information for trying this.

One Reach device is working properly, but the second one alwasy returns to ERR_CONNECTION_REF on port 80, even after having flashed it at least 6 times.
So it is not the problem to get WiFi working, the problem is, that the Intel Edison refuses to accept http entry.
Its the base device, so it is not that bad if I just start the base, let it connect to 3DR device that all works, but whenever I want to change the config in the base, I am stuck.
I

guenter · April 7, 2016, 10:15am

Another question/problem!

I want to use the usb as simple serial output at the Rover side to record nmea data.
The base info is received via UART.

BUT … when I connect the PC to the UART of the Reach Rover, I can not select the USB as output path for solution1 output, only UART shows up, not USB ???

I deactivated the USB RNDIS device driver in the PC…

Ok, I have learned, that it is NOT possible, to use/select the USB as serial output for data.(Read from a forum entry).

In the Docs is written:
Serial. You can direct the log stream to a UART or USB serial device, like a radio
THIS IS WHAT I WANT TO DO???

Now, … how to get serial nmea data as stream from the Rover? in Python3.5?

egor.fedorov · April 7, 2016, 12:50pm

Hi!

Regarding the http problem could do the following:

SSH into Reach
Run sudo systemctl status reach-setup.service -l and post the output here? Sudo password is “reach”.

Regarding the USB problem:

We do not support USB serial profile when connected to a computer, at least for now.
The option we provide requires Reach to be in host mode. USB setting will appear if you have a compatible device connected with a USB OTG wire.

guenter · April 7, 2016, 1:05pm

Hi Egor,
at the moment, after reflashing, it is working. Will post the output next time.

Regarding the USB serial profile I will try to take the serial UART TX line as output to an serial-USB CP2102 FTDI device and hope, that the UART RX line, which is connected via 3DR to the base, will not get involved. This might work. But I wonder, if I can lower the Baudrate on the TX line and leave the 115200 Baud at the RX line. I think, that does not work. (Confirmed! this does not work, but with 115200Baud it is ok, but $GPGGA (what I need every 250ms) much to slow, it takes 1,2 sec. between GPGGA sentences.

In Python (on a Win10, 64bit PC, used for handling the nmea data stream together with a magnetometer output), I have not yet found a way to receive NDIS data stream from Reach device.

guenter · April 7, 2016, 4:41pm

Hi Egor,
now it is the Rover who has stopped:

root@reach:~# sudo systemctl status reach-setup.service -l
? reach-setup.service - Basic software and network setup
Loaded: loaded (/lib/systemd/system/reach-setup.service; enabled)
Active: failed (Result: exit-code) since Thu 2016-04-07 16:33:21 UTC; 3min 17s ago
Main PID: 204 (code=exited, status=3)

SSH works on WiFi port and on 192.168.2.15 port
–red led constantly on –

root@reach:/home/reach/logs#ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

usb0 Link encap:Ethernet HWaddr 02:00:86:c5:22:78
inet addr:192.168.2.15 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::86ff:fec5:2278/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:755 errors:0 dropped:4 overruns:0 frame:0
TX packets:184 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:91232 (89.0 KiB) TX bytes:33534 (32.7 KiB)

wlan0 Link encap:Ethernet HWaddr 98:f1:70:60:7e:4a
inet addr:192.168.8.2 Bcast:192.168.8.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:430 errors:0 dropped:0 overruns:0 frame:0
TX packets:275 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:567581 (554.2 KiB) TX bytes:19991 (19.5 KiB)

egor.fedorov · April 9, 2016, 2:43pm

Hello!

Could you check the contents of a file by running
cat /etc/systemd/system/bluetooth.target.wants/bluetooth.service?

I’ve made my best guess about the problems you experience and it seems that the bluetooth service file sometimes gets corrupted.

Yesterday, I pushed v0.3.1 update to address this issue and also add a USB baud rate setting to solve your previous problem.

If the file is empty, the update will help to avoid this problem in the future.

I hope this will help. If not, don’t hesitate to report any other problems.

If you want to avoid reflashing and updating the device again, I’ve added a small instruction on how to get the unit operational.

Copy the text in the end of the post into two files in the system. It can be done via a sftp manager, like FileZilla.
Or, if you want to stay in the terminal do the following:

vim /etc/systemd/system/bluetooth.target.wants/bluetooth.service
hit : and in the command prompt below write set paste, hit enter
press i to enter vim’s insert mode and paste the text
hit : once again and write wq to save the changes and quit

Repeat the process for file /lib/systemd/system/bluetooth.service

After reboot everything should get back to normal

Contents to copy

[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)

[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/lib/bluez5/bluetooth/bluetoothd -C
NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1

[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service