Not sure where else to ask otherwise, chances are this place gets read the most by those in the know since testing beta’s involves many f/w updates and reboots. I need a way to prevent an USB GPS to be autodetected ànd added as primary GPS before Node-RED loads. When physically present I can unplug, update, reboot, log into Node-RED and use a SSH node to remove the USB GPS right after reinsertion. But obviously this won’t work remotely because I cannot unplug and Node-RED loads too late to remove (the GPS symlink) before the GPS gets added as primary GPS to VenusOS.
Any ideas, best practice?
PS , after removal the GPS data gets read via a serial node and filtered before feeding a virtual GPS.
PPS, USB GPS detection removal does not need to be persistent over firmware updates, only over reboots.
There probably is a CLI way to unload the driver, restart Node Red and reload the driver so it seems as if you unplugged and replugged the USB cable, but it’s way too late for me to come up with actual commands to test this.
I believe it’s not the serial driver that’s the issue, it’s the binding onto the priority default GPS instance (000) that, once established, prevents the virtual GPS (100) to function..
Now I better first figure out how to move this to a tread of it’s own not to further hijack the beta thread
Moved!
And don’t know how to best help; sorry.
Thanks. How do you guys do that (moving)? Can I do that myself?
The are multiple ways to do this, the most elegant one would be to allow both the physical GPS as well as the virtual GPS to be present and use the device instance number to set which one is regarded as the systemwide priority GPS.
I actually did try that already with ssh command as root but that only resulted in no GPS working at all.
I do think in general it would be a good idea to facilitate a way to allow a virtual device to be prioritized over a non virtual devices. Is this something that could be looked into?
Hope you were only referring to time of day here.
Are you interested in ‘comparing notes’?
sure, at some point - yes. But that is not a simple thing to be done by the Node-RED devs. It means changes all over the place + coordination on that.
at least the idea is there now
I wouldn’t even know where / how to find them devs 
Anyway, I think these virtual devices are a great innovation as they allow functional modifications without the need to modify/script/hack VenusOS itself.
I doubt you can do that, it will be a moderator action as we can move a series of posts from different people together.
I can not offer help on the subject of your question as I have not done anything non standard on the GX device, but before you raised the question I posted the topic below raising inconsistencies in the way GPS speed is reported when there is a virtual GPS in Node-RED. it may be of interest to you.
That’s strange behaviour. I went another route: right after insertion of an USB GPS there is some time to remove the automatically created link that makes it the system GPS. After that the USB serial port can be opened to read the raw data stream into a Node-RED flow that had plenty of dedicated nodes to proceed from there. I added some magic filtering and send to the result (at 5Hz) to the virtual GPS. Works like charm. Until reboot. Not to be big an issue but the lack of reboot persistency keeps me from publishing our solution.
What kind of filter strategy do you use? Our goal was not to compromise responsiveness for stability. Can be done but certainly not trivial.
Meanwhile I am already moving on to yet an even better solution: I’m working on a system that leverages widely popular and dirt cheap flight controller solutions to build a high-speed (5Hz plus) high precision (location, direction and speed) hardware ‘USB GPS mouse emulator’
I take the latitude and longitude from the gps into Node-RED. These update at approximately 1 second intervals. I then use the equation
Average Latitude = K x Current Latitude + (1-K) x Old Average Latitude
Same for Longitude. At the moment K = 0.03 but I am increasing this to find a good number.
I then take the average longitudes and latitudes every 5 seconds, calculate the distance between them based on the earths circumference at my latitude using the square root of the sum of the squares in metres and the 5 seconds to gives speed in m/s. The 5 seconds also provides damping, so I am also trying different values here.
I am not worried about responsiveness, I have an 18 tonne boat on the UK canals with max speed 7kph. I also set it to 0 when the engine is not running, which is how I noticed the difference between the tough screen display which was still jumping from 0 to 0.5mph but the remote console was at 0.
I took the calcs back to latitude and longitude because just averaging the speed is wrong if the gps location in jumping on and off the actual track. My method will still have some error bit will be closer to reality than just averaging speed.
For the flight control do you mean.the sort of thing used in drones / radio controlled aircraft.
Interesting, our approach is more technical. After cleaning up the NMEA data we first use non-positional data to filter out outliers, this works well under bridges for instance. Then we keep track of speed and use motor power to filter out impossible speed jumps based on maximum acceleration / deceleration foremost. Skipped datapoints are replaced by estimations/extrapolations to keep up with the roughly 1Hz update interval. This then gets fed through a rather fast weighted averaging filter of 5 datapoints with relative weights, currently: 1, 0.25, 0.0625, 0.015625 , 0.00391 (if I recall correctly). Finally only speed get then up sampled to 5Hz with linear interpolation to smooth out the boat page dial movements.
Compared to the raw datastream the results are impressive, without the delay issues of our previous approach with Karman filters. Responsiveness is great, very little delay. Stability is great as well, no noticeable ‘jitter’ and accuracy is good enough, only under bridges the speed may notably deviate from expected. The cherry on top is the up sampling of the speed data for the boat page display.
Correct. Thinking about Ardupilot with automatic sensor fusing GPS, compass and accelerometers, then send out as a standard 5Hz GPS datastream (serial over usb). The Cerbo will be non the wiser and just see a rather accurate 5Hz USB GPS.
Time of day yes, and again it’s way past my bedtime.
Not sure if there’s notes to compare, I’m not using GPS on GX, was just thinking in terms of Linux commands.
I appreciate that.
I’ve been investigating CLI based solutions but I got lost in the woods of possibilities, such as:
- Blacklisting the USB GPS VID/PID
- Scripted removal of the gps-symlink right after creation thereof
- Recoverable file system overlays to hide the gps-dbus detection script
- … And then some
For now I give up, my head is spinning.
For the future I’d love to get in touch with the virtual devices devs to discuss the ability to prioritize virtual devices over hardware devices
Meanwhile I just accept defeat and will go visit the customer site to unplug the bloody USB GPS until after the firmware update.
The issue there is that this is not something that can be solved by the “virtual devices devs”.
Its a small architectural decision, and then work by the teams of all involved parts here:
- gui-v1
- gui-v2
- vrmlogger
- vrm portal perhaps
Etc. etc.
The problem here is that venus os has no feature of selecting which gps source (be that virtual or not) to use. And adding that means changes all-over as per above. And for sure some day - but not yet
Are you sure? The mechanisms for prioritizing one over another device to be flagged as primary data source to VenusOS are already in place by means of device instance rankings, as well as the controls required to change those numeric instance rankings per device. We were aware of this prioritizing mechanism before kick-off of our gps filter project, as that seemed quite a logical and fitting general solution. But in practice we hit a brick wall with the automated device detection logic (anything hot pluggable, not just USB/GPS) not only insisting on setting device instance to 000 for an USB GPS mouse, but also for the dbus subsystem refusing to acknowledge a forced change of the instance rankings in favor of, in our case, a virtual device.
An almost equally useful feature, with general applicability, would be the ability to blacklist (previously) detected external/pluggable devices to ensure they will not be assigned any (system wide / dbus) role automatically anymore (after reinsertion/reboot/firmware updates). That would greatly simplify the development of, amongst others, pre/post processing filters in node-red or other data acquisition and processing applications.