Using GPS with RISC OS

Problems: The serial block drivers do not work on the Pi 3. The serial module in ROM currently causes a freeze unless it is unplugged if you have a GPS Hat connected (on any model of Pi). There is therefore no solution at present to use SatNav on a model 3 with a GPS module – it works in simulation mode (with no GPS module present) of course as it is written in BASIC.

How easy is it to set the baud rate to 9600 in RISC OS?

SYS "PiSerial_Speed",,9600
or
SYS "OS_SerialOp",5,7,0

Have you changed in SatNav062 or a side effect with MapView and other…
If I Start without GPS I get a “flight” around my home.
I hope more later this day…

Just a coincidence surely? You did comment that with no grid ref it did odd things… The next version will be back to Midford.

Please not change, I like it ;-)

I’m not at home but I have try any things (my wife was not amused)…
A new ROM was not working and so I try with a older one.
My old RTC was discharged when the GPS shield was plugged pemanendly. So I removed and plug the battery in the shield.

Play around with the shield… works.

Check the metadata from a photo with rRAW and export the GPS data to MapView… nearly the same.

Very nice work.

A new ROM was not working

With the GPS hat fitted, you need to unplug the Serial module (present in roms after 10 Oct 2016) for it to start up at present. Then you need to use the serial block drivers as RMReInit Serial causes the Pi to hang (with the GPS Hat connected).

Thanks for the info. Is what I would try if I back at home.

Is the “build in” RTC supported?

Is the “build in” RTC supported?

On the one hand, I’m not sure how to read it but it seems to receive partial messages, containing the time (but not date?) before any satellites come into view, so I suspect it is a blank message apart from time. On the other I don’t know how to tell RISC OS that I have a time client (like NetTime or RTC).

I understand, I think. Is not a “normally” I2C RTC. So for me it is the easier way to look at why my RTC is discharged and try to solve this problem. Maybe the BatteryMan Problem of my Pi-Top is also a “shield” problem.

Yes I’m sure there is a way: whether it is IIC or via the serial port I don’t know.

Version 0.75 uploaded (small improvement to clock error and to message protocols).

If neither SerialDeviceSupport nor PiSerial modules are present it just simulates GPS. If RXDATA line is not connected it resumes GPS once it is connected again (overcomes freeze with Serial module).

It uses messaging protocol in preference (to URI_Dispatch) but if not acknowledged it falls back to existing method (URI_Dispatch). If message to stop is received, it stops.

Also works with the Serial module, now present in Pi ROMs, tested on model A+ and model 3, but requires pin 10 (RXD) to be disconnected until the Pi has started up and baud rate and serial protocol set. No doubt this issue will be corrected in due course. Also works with PiSerial block drivers (which do not work on model 3).

Back at home I have “remount” the parts of my Pi-Top. I use only the needed 6 wire for the GPS shield. Power for the shield (3,3V) I can switch. Now a new ROM is working if I power off the shield until the Pi has started up.
B+ is working with the “build in” serial module, the Pi2 not at this time. Not sure what the reason is. Needs some more investigation.

The Pi 3 works. Haven’t tried the Pi 2. I unplug pin 10 (RXDATA) and don’t reconnect until SatNav has run. This is with just pins 1 (3.3V), 4 (5V), 6 (GND) and 10 (RXDATA) connected via flying leads.

Mmm, I have connected pin 1(3.3V), 6(GND), 8(TXD), 10(RXD), 27 (EEDATA), 28 (EECLK). Is what I read in the adafruit manual… GPIO#4 I ignore because I not need a “pulse per second”… Works with my B+. I power on (pin1) before SatNav is running.
I will try your connection at the evening.

I’ve not been following this thread, but I opened it, and saw the photo & map – and recognized the spot instantly! Saw that scene (& photographed it) from the train going from Dresden to Prague a couple of years ago! Used Googlemaps later to identify where all the photos were of.

Thats right. Well recognized ;-) I spent a few days with my family in Bad Schandau to go hiking. The Dresden-Prague railway is placed behind “our apartment”. I try the GPS stuff in my Pi-Top… my wife was not amused ;-)

Now you can use !rRaw to identify the places but you need a picture with GPS data inside. The most Smartphones do this… ;-)

I don’t have (or want) a smartphone ;-) – I have a camera with a long zoom, which doesn’t have GPS. Easy enough to find places using the map, when you know exactly where you went. The camera records the date and time of the shot, so I can pin down roughly where I was, and I’m good at relating pictures and memory to satellite views and maps.

… as I say normally… SM-Art-Phone … SM means sadomaso ;-)

8~) We do have a mobile phone. I’m not sure how old it is, but quite a few years. We put £10 on it so we could talk to our children when we left them at home (they were 22 and 20 years old) while we went on a trip eight years ago, and we haven’t run out of the £10 yet. It’s normally off, just kept charged and taken with us in case of emergencies.

I give up with my Pi2. Have pluged PIN 1, 6, 10 via the Pi-Top Hub. Works with my B+ but not with my Pi2. Same ROM other Pi-firmware. The same modules are loaded.
Try my Pi3 tomorrow but I’m not sure if I have the right firmware.
Edit: Have found the Pi3 updates ;-)

Having unplugged and plugged I am going to put a switch in the 3.3V line to sort out the problem with the Serial module (but having just looked at the recent additions to the CVS I think I may not need to). With a switch on the 3.3V line but the other lines connected, it seems to need a power on/off/on to start up from cold can’t quite read the line it stops at (about ten or so modules from the top) as I am using a 800×480 screen. Am also trying a different brand of GPS receiver but encountering teething problems as it sends slightly different messages.

Looks like my ROM was to old (13-10-2016). Starts with a plugged GPS but works only with B+, not with Pi2 and 3.
Try the ROM from your update5L and made one with the latest sources… the same. Starts no longer with a plugged GPS but “at the end of the day” it works (have only try RPi3).
If I switch on the GPS without SatNav is running, it freeze my Pi-Top.
I have try to record a track. Works if I use GPX as long as I have not a icon (second try gives the aef one) and drag the ghost to a destination folder. If I use the AEF option it reports zeros.

At the evening I will try the Pi2 and with PiTab (A+ and DSI display). Maybe I find the place to “build in” the GPS in my PiTab.

If I switch on the GPS without SatNav is running, it freeze my Pi-Top.

That has been fixed in the 26 Oct 2016 ROM (not yet tested it though).

If I use the AEF option it reports zeros.

as long as I have not a icon

Version 0.81 runs on Pi model A+, 0, 1, 2 and 3 with the latest (26-Oct-2016) ROM.

I will try the latest ROM at the evening.

Yes the Anquet Export Format ‘.aef’, RISC OS filetype &A6F, is only defined for the OSGB national grid – useful in Great Britain but not elsewhere.

Is it possible to implement a comparable grid for “elsewhere” or is it GB only?

You can still drag it to save, notwithstanding that it is invisible.

Is what I mean as I wrote “drag the ghost” ;-)
If I try a second track without changing (GPX) I get a AEF, change to AEF and back to GPX gives the GPX ghost…

Is it possible to implement a comparable grid for “elsewhere” or is it GB only?

There is a similar grid defined for Ireland. Look at the code to translate a latitude and longitude from WGS84 lat/long to OSGB lat/long and grid:

17670DEFPROCinitGB
17680REM Initialisation of constants for transformation
17690REM of latitude and longitude from WGS84 to OSGB36
17700_a = 6378137:REM // WGS84 axis
17710_e = 0.00669438037928458:REM // WGS84 eccentric
17720_a2=6377563.396:REM // OSGB axis
17730_e2=0.0066705397616:REM // OSGB eccentric
17740_xp = -446.448:REM // xp
17750_yp = 125.157:REM // yp
17760_zp = -542.06:REM // zp
17770_xr = -0.1502:REM // xr
17780_yr = -0.247:REM // yr
17790_zr = -0.8421:REM // zr
17800_s = 20.4894:REM // s
17810REM Initialsiation of constants for OSGB conversion
17820a = 6377563.396:REM // OSGB semi-major
17830b = 6356256.91 :REM // OSGB semi-minor
17840e0 = 400000:REM // OSGB easting of false origin
17850n0 = -100000:REM // OSGB northing of false origin
17860f0 = 0.9996012717:REM // OSGB scale factor on central meridian
17870e2 = 0.0066705397616:REM // OSGB eccentricity squared
17880lam0 = -0.034906585039886591:REM // OSGB false east
17890phi0 = 0.85521133347722145:REM // OSGB false north
17900af0=a*f0
17910bf0=b*f0
17920ENDPROC
17930:
17940DEFPROCconv(long,lat)
17950rlat=lat*PI/180
17960rlon=long*PI/180
17970h=0
17980sf = _s * 0.000001
18000v = _a / SQR(1 - (_e * SIN(rlat) * SIN(rlat)))
18020x = (v + h) * COS(rlat) * COS(rlon)
18040y = (v + h) * COS(rlat) * SIN(rlon)
18060z = ((1 - _e) * v + h) * SIN(rlat)
18070xrot = (_xr / 3600) * PI/180
18080yrot = (_yr / 3600) * PI/180
18090zrot = (_zr / 3600) * PI/180
18100hx = x + (x * sf) - (y * zrot) + (z * yrot) + _xp
18110hy = (x * zrot) + y + (y * sf) - (z * xrot) + _yp
18120hz = (-1 * x * yrot) + (y * xrot) + z + (z * sf) + _zp
18140Nlon = ATN(hy / hx)
18160p = SQR((hx * hx) + (hy * hy))
18180Nlat = ATN(hz / (p * (1 - _e2)))
18190v = _a2 / SQR(1 - _e2 * SIN(Nlat)*SIN(Nlat))
18200errvalue = 1.0
18220WHILE errvalue > 0.001
18230 lat0=ATN((hz + _e2 * v * SIN(Nlat)) / p)
18240 errvalue=ABS(lat0-Nlat)
18250 Nlat=lat0
18260ENDWHILE
18270REM Nlat,Nlon are new lat,long in radians
18280phi = Nlat
18290lam = Nlon
18300REM Easting:
18310slat2=SIN(phi)*SIN(phi)
18320nu=af0/SQR(1-(e2*slat2))
18330rho=nu*(1-e2)/(1-(e2*slat2))
18340eta2=(nu/rho)-1
18350p=lam-lam0
18360IV=nu*COS(phi)
18370clat3=COS(phi)*COS(phi)*COS(phi)
18380tlat2=TAN(phi)*TAN(phi)
18390V=(nu/6)*clat3*((nu/rho)-tlat2)
18400clat5=COS(phi)*COS(phi)*COS(phi)*COS(phi)*COS(phi)
18410tlat4=TAN(phi)*TAN(phi)*TAN(phi)*TAN(phi)
18420VI=(nu/120)*clat5*((5-(18*tlat2)) + tlat4 + (14*eta2) - (58*tlat2*eta2))
18430xgrid=e0+(p*IV)+(p*p*p*V)+(p*p*p*p*p*VI)
18440REM Northing:
18450n=(af0-bf0)/(af0+bf0)
18460M=bf0*(((1+n+((5/4)*(n*n))+((5/4)*(n*n*n)))*(phi-phi0))-(((3*n)+(3*(n*n))+((21/8)*(n*n*n)))*(SIN(phiphi0))*(
COS(phi+phi0)))+((((15/8)*(n*n))+((15/8)*(n*n*n)))*(SIN(2*(phi - phi0)))*(COS(2*(phi+phi0))))-(((35/
24)*(n*n*n))*(SIN(3*(phi-phi0)))*(COS(3*(phi+phi0)))))
18470I=M+n0
18480II=(nu/2)*SIN(phi)*COS(phi)
18490III=((nu/24)*SIN(phi)*COS(phi)*COS(phi)*COS(phi))*(5-TAN(phi)*TAN(phi)+(9*eta2))
18500IIIA=((nu/720)*SIN(phi)*clat5)*(61-(58*tlat2)+tlat4)
18510ygrid=I + (p*p*II) + (p*p*p*p*III) + (p*p*p*p*p*p*IIIA)
18520ENDPROC

change to AEF and back to GPX gives the GPX ghost

Curses – another bug!

The German Gauß-Krüger, the “NATO” UTM, ITM (the “new Irish grid”) and other grid system based on Transverse Mercator are similar as OSGB and the “old” Irish Grid but calculates with a different shape of the earth. Fortunately, most use of the same shape of the earth as WGS84, which makes it somewhat easier. Not too difficult are the Lambert grid systems such as those of Belgium and France. Tricky are the grid systems used in the Netherlands and Switzerland.

My attempt in php: https://github.com/WouterRademaker/mediawiki-coorconv

Thanks for the info. I know Thomas has play around with Gauß-Krüger but not sure if MapView can handle…

Back to SatNav…

After Jeffreys answer in the Pandora-thread I could not resist…

Have solder a serial cable for my Pandora…

… and connected to the RPi GPS …

… works…

Edit: I forgot…

That has been fixed in the 26 Oct 2016 ROM (not yet tested it though).

Latest ROM (compiled “zpp free” last night) works fine. Can start my Pi-Top with plugged GPS.