GPS and RISC OS

I’d like to use a RPi as the ‘brains’ behind an integrated autopilot and navigation kit for my boat. At present, I’m unclear (confused!) on how best to connect my GPS receiver to the Pi. Several questions are unresolved:
(1) RISC OS is my preferred OS (too old to learn new tricks) but my GPS is Bluetooth enabled. Getting it to communicate with the Pi via Bluetooth & RISC OS appears problematic. Am I missing something? Or expecting too much?
(2) I’m using an ACER wireless keyboard and mouse with the Pi. That wireless connection appears to operate completely successfully with RISC OS. Any chance I could adapt that connection for use with GPS (if necessary, with some other receiver)?
(3) My researches so far seem to indicate that I’m more likely to be successful if I abandon RISC OS in favour of Linux. I’d be reluctant – but is this the best option if I want to make progress anytime soon?

I mean Thomas Milius works on seriell GPS via his FTDI Driver.

DavidS: Is it really going to be that simple? I’ll give it a go. Any specific recommendation for the GPS receiver? Thanks for the advice.

Raik: Sorry, your response is a little too cryptic for me. Would you be kind enough to explain? (What’s an ‘FTDI Driver’? And how do I find out about them?)

FTDI is one ofe the possible chips in a USBtoSerial-adapter. Thomas Milius has a Driver for it. Sorry for my bad english.

Have you looked at http://fishpi.org/ ? OK, it’s not RISC OS, but it may give you some ideas.

Thanks for your comments.

Raik: Not your English – its my knowledge of electronics which is wanting. I was hoping to complete my project without having to descend to low-level coding (RPi is supposedly designed to encourage beginners to tinker!) So, for the moment, I’m trying to maintain a ‘higher level’ approach (see below).

neil.r: Yes, I had seen the FishPi programme. Quite impressive: they clearly have sufficient expertise to follow a thorough top-down approach. It does seem, however, to be thoroughly committed to the Linux-Python software option. I acknowledge that this offers considerable practical advantages from my perspective (not least, the ready incorporation of Gertboard technology & software). I may have to give in and head that way in the end – but, at the moment, I’m resisting the ‘overhead’ of having to learn yet another OS and programming language (especially when my project is itself in personally unfamiliar technical territory).

I wrote something that used a compact flash GPS receiver on a Psion Netbook. It was plugged via a mechanical adapter into the PCMCIA port and simply presented itself as a serial port with ASCII data. Very simple.

I doubt the Bluetooth version is much different.

Getting it to communicate with the Pi via Bluetooth & RISC OS appears problematic.

The problem is that, as far as I know, there is no “bluetooth stack” for RISC OS. Because RISC OS is very small, things like this tend to come when somebody with the required skills/knowledge has a need for it.

I, too, have a little Bluetooth USB dongle and an old Bluetooth GPS receiver ¹. Not tried it with RISC OS, but I’d be very surprised if it worked.

¹ Don’t use it anymore as all of my Android phones have GPS/compass/etc built-in…

Thanks, all – I think this is encouraging; at least there’s enough there to make a start. RISC OS will let me get through to the GPIO pins and a documented GPS module should allow me to download the NMEA sentences.
However, I’m warned against raw access to the GPIO pins: is there any RISC OS support for the Gertboard – or a RISC OS equivalent?
This looks like an appropriate way forward (I think I understand what I’m doing) and I’m happy nto leave the Bluetooth option aside for the time being.
Again, many thanks for your help.

Funny you should mention that – I’ve been playing with my Gertboard this morning, trying to WIMPify my LED chasing program. Whilst I’m sure any Real Programmer could do this in 12 seconds flat, it’s taken me all morning so far just to create a template of a window. And I now know the difference between ‘icons’ and ‘furniture’. So that’s a step forward I guess.

Anyhow – to answer the question (sort of) – yes, you can play with the Gertboard from RISC OS, and it works for both input and output – I’ve kludged the LEDs and Buttons programs to work from BASIC ¹ using the !GPIO module, which you can get from !PackMan. The reason for the warning about access straight to the GPIO pins is that if you get it wrong, you can blow up the pi, whereas the Gertboard provides some protection. Now, seeing as the pi is cheaper than the Gertboard, I’m less than convinced on this point to be honest.

¹ I was going to try recompiling the examples written in C, but I don’t know enough about the language to remove the unix specific parts, like the reliance on /dev/mem

neil.r: I’ve just had a play with the !PiLed demo that comes with the GPIO module software. WIMPifying that presented no particular problem (another learning curve, but at least it’s well documented) so I moved on to your(?) BASIC code for the Gertboard ‘marching LEDs’ demo. The Gertboard is on order (it offers a number of advantages for my application, particularly the potential to control motors rated at a few tens of watts – and I really do need to protect my delicate ‘brain’ from the marine environment) so I’m looking forward to that ‘learning curve’ – but I’m encouraged to believe that interacting with the ‘real’ world might be less daunting than I thought at first.
I still have some concerns about the hook-up to GPS but I’m also pursuing the suggestions from DavidS and hope I can resolve these soon (the Bluetooth option is completely on the back burner now: it’s just not necessary for my application).

I’ve done a bit of playing with motors through the Gertboard, and that’s pretty straightforward too – I hooked up a couple of ducted fan units and a 3S1P li-po pack that I had going spare, which worked perfectly. I don’t think I ever kept the code for that, as it was so similar to the example code that ships with the Gertboard.

The LED chasing program, however, has transformed into a WIMP enabled application (snappily titled !LEDs until I can think of something better) with the help of DrWimp. I just need to find a suitable set of sprites now. The plan now is to work through the rest of the Gertboard sample programs, converting them to BASIC where I can. Hopefully this will encourage a few more people to pick up RISC OS when they see how easy it is to do. One thing I’ve found about children and computers is that they are far more interested when the computer does something like switching a motor on, rather then just displaying a character on a screen. Well, not just children come to think of it…

neil.r: Still waiting for Gertboard – and its too cold to go down to the boatyard to see if I can ‘read’ the NMEA sentences produced by my existing GPS receiver. So further developments on hold for the present.
However, I’m interested in any BASIC coding that sets up the GPIO pins for input then reads the input stream(s) – lots of scope for confusion here, so any assistance from prior experience would be very welcome.
Totally agree with your comments on kids & computers: my grandson and his mate (both computer literate) are arriving for the weekend, the Pi is up and running and the old train set is still set up in the loft….

Here’s some very old code for reading NMEA GPS data, completely untested, no documentation whatsoever:

www.datafilehost.com/download-de3b116d.html

NMEA isn’t that hard to parse. Spec here: http://aprs.gids.nl/nmea/

The hard part, of course, is being able to read it in the first place.

Yeah, the above came from “TimB” over at boatdesign.net, who was quite surprised when I inquired about it:

Wow, that must have been a really old post! I used to (10 years ago) use a Strongarm RiscPC (ROs 3.7?) as my main desktop machine. I used it for everything from development to report writing and web surfing, and it gave sterling service. I did manage to get a serial NMEA feed into it, using BASIC although I can’t remember whether I actually got to parsing the sentences.

He sent me the code, saying that

This was the forerunner project to OpenPilot, which revolved around putting a RiscPC at the centre of a vessel’s monitoring and navigation system. It isn’t maintained, and the old software is presented here for interest and posterity as much as anything. The code was written in BBC Basic V, with all hardware IO operations done using system calls. A simple GUI outline was produced, but that was as far as it went.
In some ways it is a shame that the ACORN computers and RiscOS have slipped quietly into the annals of history, overshadowed by the brash alternatives. These machines were revolutionary though, not just in their ROM-based OS, but in providing a simple, stable, powerful machine on the desktop, in a time when PC users could only dream of a graphical interface. However, there was another advantage of the ACORN era; Programming. The BBC Micro was developed to support education, and part of this was in making it easy to program. The later ACORN machines improved the language, but BBC BASIC was and is (especially with v6) one of the finest examples of the BASIC language ever produced.
It is only recently that we have seen a system which can offer a similar level of new-programmer-friendliness; Linux. The whole mindset behind Linux is that you develop what you need and share it for the good of all. Because of this, the system becomes written for developers, and that produces a nice environment to develop under. Linux has for some time been the OS of choice for embedded platforms, for financial and development reasons, and as the prevailing embedded technology appears to be ARM, perhaps we will see OpenPilot running on an ARM chip after all, just under a different OS.
— TimB – 20 Nov 2010

I’m interested in any BASIC coding that sets up the GPIO pins for input then reads the input stream(s) – lots of scope for confusion here, so any assistance from prior experience would be very welcome.

“GPIO_WriteMode” is used to set the GPIO mode, so if you use 0 then the pin becomes an input.
Then you just use “GPIO_ReadData” in a loop to monitor the pin.

However, I’m interested in any BASIC coding that sets up the GPIO pins for input then reads the input stream(s) – lots of scope for confusion here, so any assistance from prior experience would be very welcome.

I’ve got a bit of BASIC that reads the three pushbuttons on the Gertboard – I’ll dig it out later and post it up. Need to get out to my shed first, and that will require several large mugs of tea.

Thank you: all very helpful.
The GPIO module makes it very easy to set up the RPi pins; as noted, however, that set up must correspond to the input stream spec. TimB’s old code does this by making use of low level OS_SerialOp calls which, I presume, worked successfully on his serial port configuration. His coding also exemplifies NMEA sentence parsing – so thanks, patric, for passing that on: I’ll try adapting it when I have access to a receiver (fortunately, he used lots of REMs and mnemonic variable names, so adaptation should be fairly straightforward).
So thanks, everyone, for all your help: I love it when a plan comes together!

I love it when a plan comes together!

http://www.youtube.com/watch?v=wyz_2DEah4o ;-)

I’ve got a bit of BASIC that reads the three pushbuttons on the Gertboard – I’ll dig it out later and post it up.

Here goes:

DIM b%(11)
REM
REM First step - check we're on a Pi, just bail out if otherwise
REM
SYS "GPIO_GetBoard" TO a%
IF a% = 11 OR a% = 12 THEN
 PRINT "These are the connections for the buttons test:"
 PRINT "jumpers in every out location (U3-out-B1, U3-out-B2, etc)"
 PRINT "GP25 in J2 --- B1 in J3"
 PRINT "GP24 in J2 --- B2 in J3"
 PRINT "GP23 in J2 --- B3 in J3"
 PRINT "Optionally, if you want the LEDs to reflect button state do the following:"
 PRINT "jumper on U3-out-B1"
 PRINT "jumper on U3-out-B2"
 PRINT "jumper on U3-out-B3"
 PRINT "When ready hit any key."
 temp%=GET
 PRINT "Press escape at any time to exit."
 REM
 REM build array to map LEDs to GPIO
 REM
 REM ***
 REM this is a bodge! My board misidentifies. We should match a% to 11.
 REM ***
 IF a% = 12 THEN
  REM set pin to LED mappings for rev A
  b%() = 7,8,9,10,11,17,18,21,22,23,24,25
 ELSE
  REM Set pin to LED mappings for rev B
  b%() = 7,8,9,10,11,17,18,27,22,23,24,25
 ENDIF
 REM
 REM set last three pins to input, pull enable, pull up on press
 REM bits 0-2 = Mode (0 = GPIO Input)
 REM bit 3 = Pull enable (0 = off 1 = on)
 REM bit 4 = Pull type (0 = down 1 = up)
 REM
 FOR x% = 9 TO 11
  g%=b%(x%)
  SYS "GPIO_WriteMode" ,g%,24 TO a%
  ENDIF
 NEXT
 REM
 REM read the three buttons. it looks odd using 9,10, and 11 but we're
 REM patching the buttons to GPIO 23,24 and 25
 REPEAT
  FOR x% = 9 TO 11
   y% = x%
   PROC_readpin(y%)
   IF y% = 0 THEN
    PRINT "button " x%-8 " pressed"
    PROC_delay(10)
   ENDIF
  NEXT
 UNTIL FALSE
ENDIF
END

DEF PROC_delay(delay%)
  tnow%=TIME
  REPEAT
  UNTIL TIME>tnow%+delay%
ENDPROC

DEF PROC_readpin(pin%)
  SYS "GPIO_ReadData", b%(pin%) TO y%
ENDPROC

Yes – ‘The A-Team’ – wonderful support!
The Gertboard now installed and I’m trying to get a grip. The BASIC code from neil.r is extremely helpful: it matches up fairly clearly with the C and Python code associated with the corresponding examples in the Gertboard User Manual so I’ll try ‘going solo’ on the BUTLED example there, which might begin to address my concerns about reading externally controlled input streams. That is still a major question mark which I can’t tackle till I rig some sort of access to an appropriate input source (too cold – & wet – to run experiments on the boat GPS: I may have to invest in DavidS’s suggestion).
Head down and bite the bullet, I guess. Should keep me off the streets for a day or two.

Hi!
Just in case anyone is still interested, I thought I’d better finish this story – at least, as far as it has progressed so far. – as others may find my experience useful.
1. Access to GPS was finally obtained using Terry Swanborough’s code (@ www.mbelect.demon.co.uk/uart.zip). Worked beautifully with a Pmod GPS but I can see no reason why it shouldn’t work with any other chip. NMEA parsing using Basic proved more than fast enough with the Pmod, allowing ample time for control & display tasks based on GPS data between ‘reads’.
Any chance this code could be converted to a relocatable module?
2. Gave up on the Gertboard option: mine had to be returned as faulty and the Pmod could be wired directly to the Pi GPIO pins (carefully!). Not ideal – but we’re still at the protoype stage.
3. Remaining issues in way of final target appear surmountable (mainly concerned with access to and use of large, raster-scan charts) – but progress has been slow. My fault – nothing to do with the Pi or RISC OS, both of which remain impressive.
4. So much so, in fact, that even when all the navigational tasks have been taken care of, there appears to be ample computational reserve to consider incorporating voice control. Anyone know of any good voice recognition code out there (RISC/BBC Basic, of course)?

Jim,
There is a full serial driver available
http://tankstage.co.uk/Software/PiSerial.zip
Note also it is most likely necessary to change the speed calculation in Terry’s code. Acknowledged by Terry, but not changed yet in the driver at your link.

DEFPROCSet_BaudRate(baud%)
sum=3000000 / (16*baud%) :REM fuart / (16*baud)
I%=sum :REM integer only
F%=(sum-3000000 DIV (16*baud%))*100 :REM 2 decimal place fraction
IF baud%=115200:I%=1:F%=40 :REM bodge for 115200 ?

should be changed to

DEFPROCSet_BaudRate(baud%)
sum=3000000 / (16*baud%) :REM fuart / (16*baud)
I%=sum :REM integer only
F%=((sum-I%)*64+.5) :REM 2 decimal place fraction as an integer

The error was noticeable at 38400 in my tests, but note that Terry’s 115200 bodge actually conforms to the latter formula.

Thanks, Ronald.
Very satisfactory correction for Terry’s code: essentially, a rounding error problem so all is explained.
I’ve had a quick play with PiSerial – though full incorporation will have to wait until I’m not distracted by my chart problems. But, once again, many thanks.