Some models of Cisco routers have inbuilt GPS antennas and it is possible to get location data from the router, using both CLI and SNMP.
Is it possible to add code in NAV to import this GPS data into the "Position" field in the "Rooms" data?
For routers that are in a static location it means the location will be correct, not a best effort by pointing on a map. :-)
For routers that are in motion it means it is possible to track them and at least know the last location.
lng-truck-1-L22#show cellular 0 gps detail
GPS Info ------------- GPS Feature: enabled GPS Port Selected: Dedicated GPS port GPS State: GPS enabled GPS auto tracking status: unknown GPS auto tracking config: disabled GPS Mode Configured: standalone Latitude: 60 Deg 28 Min 54.7647 Sec North Longitude: 5 Deg 23 Min 22.7313 Sec East Timestamp (GMT): Wed Aug 30 09:46:56 2017
Fix type index: 0, Height: 81 m HDOP: 0.8, GPS Mode Used: standalone
Satellite Info ---------------- Satellite #2, elevation 17, azimuth 42, SNR 34 Satellite #9, elevation 11, azimuth 347, SNR 35 Satellite #16, elevation 17, azimuth 288, SNR 39 Satellite #21, elevation 25, azimuth 177, SNR 38 Satellite #23, elevation 15, azimuth 320, SNR 42 Satellite #25, elevation 27, azimuth 123, SNR 43 Satellite #26, elevation 45, azimuth 282, SNR 46 Satellite #29, elevation 65, azimuth 88, SNR 34 Satellite #31, elevation 45, azimuth 222, SNR 43 Satellite #5, elevation 16, azimuth 75, SNR 0 Satellite #20, elevation 6, azimuth 118, SNR 0
roger@nav:~$ snmpwalk -On -c secretpw -v 2c 10.140.73.1 1.3.6.1.4.1.9.9.661.1.4.1.1.1 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.1.16 = INTEGER: 2 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.2.16 = INTEGER: 2 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.3.16 = INTEGER: 48 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.4.16 = STRING: "59 Deg 25 Min 24 Sec North" .1.3.6.1.4.1.9.9.661.1.4.1.1.1.5.16 = STRING: "5 Deg 25 Min 26 Sec East" .1.3.6.1.4.1.9.9.661.1.4.1.1.1.6.16 = STRING: "GMT: Wed Aug 30 10:00:17 2017 " .1.3.6.1.4.1.9.9.661.1.4.1.1.1.7.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.8.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.9.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.10.16 = INTEGER: 2 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.11.16 = INTEGER: 1 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.12.16 = INTEGER: 19 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.13.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.14.16 = INTEGER: 2 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.15.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.16.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.17.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.18.16 = Gauge32: 0 .1.3.6.1.4.1.9.9.661.1.4.1.1.1.19.16 = Gauge32: 11
1.3.6.1.4.1.9.9.661.1.4.1.1.1.1 (c3gLbsModeSelected) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.2 (c3gLbsState) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.3 (c3gLbsLocFixError) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.4 (c3gLbsLatitude) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.5 (c3gLbsLongitude) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.6 (c3gLbsTimeStamp) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.7 (c3gLbsLocUncertaintyAngle) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.8 (c3gLbsLocUncertaintyA) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.9 (c3gLbsLocUncertaintyPos) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.10 (c3gLbsFixtype) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.11 (c3gLbsHeightValid) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.12 (c3gLbsHeight) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.13 (c3gLbsLocUncertaintyVertical) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.14 (c3gLbsVelocityValid) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.15 (c3gLbsHeading) 1.3.6.1.4.1.9.9.661.1.4.1.1.1.16 (c3gLbsVelocityHorizontal)
Best regards, Roger
Hi Roger!
Nice idea. I wasn't aware of this feature from Cisco (could be because I do not follow feature- and hardware trains as close anymore). What Cisco platforms typically support this? And will more in the future, do you think?
cheers, - Vidar
On 30.08.2017 10:13, Roger Aas wrote:
Hi Vidar,
Long time no see ;-)
I have a customer with Cisco IR809 and IR829 industrial routers that have this feature and that I have programmed and tested myself.
I also know that the Cisco 819, 880G and 890G ISR routers have the same feature.
There is also a module for different types of ISR G2 routers (19XX, 29XX and 39XX) that can be connected to an antenna with GPS, the Cisco 4G Enhanced High-Speed WAN Interface Card (EHWIC). These cards are bought by many to be used as a backup 4G/3G link in case the cable/fiber connection is down. The GPS is just an added bonus on this card.
And there is network interface modules (NIM) for the new 4000 series routers, f.ex. the Cisco LTE Advanced 3.0 NIM and the Cisco LTE 2.0 NIM that support GPS, that do the same for those types of routers.
If there are more routers or other boxes that support GPS and what the plans are for the future I am not sure, but it seems to me that all new boxes that support 4G inbuilt or via a card have GPS also.
So if you get any data from this SNMP MIB it means this router have GPS capability and it should be possible to use it in NAV.
Actually, the 829 industrial router also have accelerometer and gyroscope just like a modern smartphone so it is possible to have alarms if those values are outside some set limits, ie the router can inform operations that the truck have crashed, in real time.
With high regards to the Uninett crew,
Roger
On Wed, 30 Aug 2017 08:13:02 +0000 Roger Aas Roger.Aas@atea.no wrote:
Cool :-)
Is it possible to add code in NAV to import this GPS data into the "Position" field in the "Rooms" data?
It would be possible, but what happens in the case where there may be multiple GPS-capable routers registered in the same NAV room? Which router should be authoritative for the room location?
Also, how often should the room position be updated? For a router in a trailer, updating every 6 hours would be too slow. For a stationary router, updating every 5 minutes would be a waste of resources ;)
For routers that are in a static location it means the location will be correct, not a best effort by pointing on a map. :-)
How is the GPS coverage inside buildings these days? :)
roger@nav:~$ snmpwalk -On -c secretpw -v 2c 10.140.73.1 1.3.6.1.4.1.9.9.661.1.4.1.1.1
CISCO-WAN-3G-MIB. Good to know :)
I was thinking the same, but decided that it would not much matter, if there are several GPS-capable routers in a single room the GPS data would not differ much, so the room could just get the GPS data from the last box that was read, no matter the order you read them in.
It would be a much larger job and probably a redesign of the program to move the location data to each netbox instead of the room.
Also, how often should the room position be updated? For a router in a trailer, updating every 6 hours would be too slow. For a stationary router, updating every 5 minutes would be a waste of resources ;)
For this specific customer they are not that interested in real-time positioning of their trailers so a timescale of hours would be fine. But maybe some other NAV users would like a more rapid update cycle. If NAV had a default update period of f.ex. 6 hours, but it was possible to change that on a room by room basis, if the case where you have "rooms" that "move about", that would be nice. A GPS-capable router on a trailer is configured in a "room" called "Trailer L22" for example, so you would want to change the update frequency for that particular room, not for a GPS-capable router in f.ex. an LNG station that is stationary.
Really bad, but that is why the cable for the GPS antenna is normally longer than that for the 4G antenna. ;-) Normally the GPS antenna is placed on the outside to get a line of view to the satellites, while the 4G coverage is perhaps sufficient inside the room. If not, get extender cables for the 4G antennas also.
But we use these industrial routers from Cisco because they are certified for hazardous locations and manage temperatures outside normal room temperatures :-)
Cisco IR829 Environmental operating range: -40° to 140°F (-40° to 60°C) in a sealed NEMA cabinet with no airflow -40° to 158°F (-40° to 70°C) in a vented cabinet with 40 lfm of air -40° to 167°F (-40° to 75°C) in a forced air enclosure with 200 lfm of air
so we install the router in a metal cabinet on the outside wall with a IP67 waterproof dome antenna (4G + Wifi 2.4GHz/5GHz + GPS) on top of the cabinet. This works very well.
So, any hope of getting this GPS data in a future release? :-)
- Roger
-
Morten Brekkevold -
Roger Aas -
Vidar Faltinsen