I did it again and this time it worked. Very cool! It is about 5x slower than flashing with ST-LINK or VS Code though.
Posts made by zhihengcao
I followed the instruction on https://openrtk.readthedocs.io/en/latest/useOpenRTK/Go-Mobile.html
In the step
"Open the “OpenRTK” Andorid App, as shown by the picture below, go to the “Connect” tab and click the “search” icon (right bottom) to search for your device."
There phone does not find the EVK.
I tried flashing to the factory original firmware, it cannot be found. The android phone has Bluetooth turned on. I can find other previously used BT devices.
Thank you, I have been reading this example and it helps me understand the system a lot.
The RPK/INS correction is your proprietary and done inside a closed source library (.a file). This is totally fine, but the example firmware only demonstrates correction in real time assuming Base RTCM data stream from UART or BT or HTTP.
I am looking to implement Post Processing, the firmware stores the IMU and GNSS raw data into on-board memory, then receive archived Base RTCM data stored in the past, to run your proprietary library. Can you tell me if this is something that can be achieved with your proprietary library without limitations? Does your proprietary library have some restrictions, like it has to be run based on realtime/live data? Does it have restrictions it has to be run in combination with some hardware & firmware? In other words, do you limit your proprietary library to run only on the OpenRTK module, or can it be ported run on any ARM processor?
No RED LED:
http://192.168.137.110/runStatus.shtml shows:
Station Mode:
NTRIP-CLIENT
Station Status:
NTRIP-CLIENT & CONNECTED
Red LED flashing:
http://192.168.137.110/runStatus.shtml shows:
Station Mode:
OPENARC-CLIENT
Station Status:
RTCM AVAILABLE
Correction! It appears the "NTRIP" mode configured in firmware does not really work through the Ethernet, the "RED" led only lights up in "OpenArc Client" mode. So there appears to be a bug that makes the NTRIP mode only work through Python Driver, while Openarc client works through the Ethernet without Python Driver. Please fix the bug so NTRIP can also work through the Ethernet without Python driver running.
To answer my own question, the 58.215.20.43 along with username/password is specified in openrtk.json file of settings folder of the Python driver, and it works. The 47.116.1.17 along with another username/password is baked inside the firmware and does not work. So I put the info from openrtk.json via http://192.168.137.110/workCfg.shtml into the firmware, now I see the "RED" LED flash even without Python driver running, as long as the Ethernet cable is plugged into somewhere with Internet access.
It seems the "Upgrade" button in developer.aceinna.com for GNSS_RTK_INS always fails and bricks the device until I use ST_LINK to flash the entire device with the backup bin. The slider in the screenshot below never moves past 0.02%.
I noticed that even when Ethernet is connected and has Internet access, the "RED" LED does not light up (indicating no data from NTRIP) unless I start also the Python driver.
Also, the Python driver reporting connecting to "58.215.20.43" regardless of the setting I put in http://192.168.137.110/openarcclientcfg.cgi "Work Config", If I put NTRIP Client mode IP=47.116.1.17 or OpenARC client IP=openarc.aceinna.com (52.183.58.220) the Python driver still connects to 58.215.20.43. Where is this IP address 58.215.20.43 coming from? How can I change it to NTRIP server that is local to my position so the RTK will actually work in my location?
I plan to write the STM32 firmware that run inside your module, to connect via I2C or SPI to a SD card module to store data.
My application will not have reliable Internet connection during logging, so my goal is to store the "rtcm_rover_xxx.bin" data and IMU "user_xxx.bin" data in the SD card then when Internet becomes available, send these data to our server to perform PPK + INS using something like https://www.eye4software.com/hydromagic/documentation/articles-and-howtos/ppk-surveys/
Please let me know if OpenRTK can be used for this.
I am reading https://www.eye4software.com/hydromagic/documentation/articles-and-howtos/ppk-surveys/ Can you support this flow to allow OpenRTK to be used this way?
When Internet is not available during data logging, can past RTK Base RTCM data (rtcm_base_xxxx.bin) be downloaded from somewhere?
In the tutorial https://openrtk.readthedocs.io/en/latest/useOpenRTK/On-a-PC.html
It says below but there is no such folder or tool called openrtk_data_parse or openrtk_parse.exe anywhere to be found, including everywhere in github.
Go to the “openrtk_data_parse” subfolder, run the parser executable as below
cd c:\pythondriver-win\openrtk_data_parse
.\openrtk_parse.exe -p ..\data\openrtk_log_20201217_141618
A subfolder with the name “user_xxxx_xx_xx_xx_xx_xx_p” is created and contains the decoded files all in ASCII format, e.g.
Ultimately, my application is PPK, to have the device log in NIMEX format without requiring PC connection or running the Python program.
In my application, Internet connection is not always available.
Do you think if NTRIP or Internet connection is not available, the INS accuracy will be severely reduced? Can PPK post correction fix the INS accuracy?
Thanks. Do I need the Python driver running on a PC always in order for RTK to work?
Can I plug in the Ethernet to a travel router with Internet access and not connect the USB/UART & Python driver, but still have the system logging data? Or must I take a laptop with the Python running when carrying it on a test vehicle/aircraft?
I think since there is onboard M4 ARM processor, you could write firmware to connect to NTRIP through the Ethernet and log data. Where can I find any example firmware with source code?
Please also help me with my other thread to get the INS to work to get higher than 1Hz fix update rate.
I keep seeing as below the INS status is invalid:
Even though I can see the raw IMU data at
The position update rate seems to be 1Hz indicating that dead-reckoning is not working.
Despite the connection to openarc, the position error seems to be several meters as the position wanders over 2~3 meters (GPS antenna and EVM is completely stationary):
Looks like bootloader alone does not connect to developer.aceinna.com
I followed the instruction at https://forum.aceinna.com/topic/289/how-to-update-firmware-after-online-update-fails/6
To manually upgrade OpenRTK330L_GNSS_RTK_INS_v23.05.bin using --cli in python driver and now it connects after running python driver again after updating.
OK, now it works after I remove the "-b 115200 "
Do I need to apply the calibration data since I erased everything using ST-LINK?
I went to https://developers.aceinna.com/devices/owned/2075000294 clicked "DOWNLOAD" under "Calibration Data" but got
"There is some error while generate download link. " Can you fix it? Also please let me know the instruction to apply the downloaded calibration data.
The orange/green LED now started to flash after power cycle like it did before, but still Python driver does not connect:
(base) C:\Users\breez\python-openimu>python main.py -b 115200 --console-log
[Info] Python driver version: 2.5.0
2021-07-15 00:35:35,621 - INFO: try to use last connected port COM3 115200
[Info] Websocket server is started on port 8000
2021-07-15 00:35:40,568 - INFO: start to connect serial port
2021-07-15 00:35:40,571 - INFO: try to use connected port COM6 in history
2021-07-15 00:35:40,571 - INFO: try COM6:115200
2021-07-15 00:35:40,572 - INFO: try to use connected port COM5 in history
2021-07-15 00:35:40,573 - INFO: try to use connected port COM4 in history
2021-07-15 00:35:40,573 - INFO: try COM5:115200
2021-07-15 00:35:40,573 - INFO: try to use connected port COM3 in history
2021-07-15 00:35:40,584 - INFO: try COM4:115200
2021-07-15 00:35:45,116 - INFO: try COM3:115200
2021-07-15 00:35:50,580 - INFO: try to use last connected port COM3 115200
2021-07-15 00:35:55,569 - INFO: start to connect serial port
2021-07-15 00:35:55,571 - INFO: try to use connected port COM6 in history
2021-07-15 00:35:55,571 - INFO: try COM6:115200
2021-07-15 00:35:55,572 - INFO: try to use connected port COM5 in history
2021-07-15 00:35:55,573 - INFO: try to use connected port COM4 in history
2021-07-15 00:35:55,573 - INFO: try COM5:115200
2021-07-15 00:35:55,573 - INFO: try to use connected port COM3 in history
2021-07-15 00:35:55,573 - INFO: try COM4:115200
2021-07-15 00:36:00,305 - INFO: try COM3:115200
2021-07-15 00:36:05,793 - INFO: try to use last connected port COM3 115200
2021-07-15 00:36:10,716 - INFO: start to connect serial port
2021-07-15 00:36:10,719 - INFO: try to use connected port COM6 in history
2021-07-15 00:36:10,719 - INFO: try COM6:115200
2021-07-15 00:36:10,720 - INFO: try to use connected port COM5 in history
2021-07-15 00:36:10,721 - INFO: try to use connected port COM4 in history
2021-07-15 00:36:10,721 - INFO: try COM5:115200
2021-07-15 00:36:10,721 - INFO: try to use connected port COM3 in history
2021-07-15 00:36:10,722 - INFO: try COM4:115200
2021-07-15 00:36:15,306 - INFO: try COM3:115200