RISC OS, Family Trees and GPS

What's on show?

My new !FamTree software will be released at the show. It is priced at 15 and allows a graphical family tree layout to be produced.

I had the idea that relationships could be defined by means of the directory structure: each directory would represent an individual or couple and there would be a sub-directory for each child of the relationship. A tree structure could then be produced, arranged vertically. Each directory would contain a text file providing the detailed information that would appear in the box and I would arrange some form of editing on screen to move the boxes around to make best use of the space.

When this directory structure is loaded into the application !FamTree, a draw graphic of the implied family tree is produced with the boxes widely spaced to be out of each others way. This is shown in a work area window and will recognise mouse clicks on the individual boxes interpreting such clicks as demands to move left or right. With SHIFT held down, the movement is up and down. Holding CTRL as well magnifies the movement. After a little bit of editing, the graphic appears as given below. It uses space economically allowing a quite complex family tree (going back to 1750) to be created on 297mm x 1200mm paper, which I can print on my A3 colour laser printer.

The FamTree application also supports the import of files in the standard GEDCOM 5.5 format.

GPS Unit

I'll also be exhibiting the latest version of my SatNav application now running in a 3½″ x 2¼″ x 2″ box with a small internal battery which can float charge itself if an external battery or other 5V power source is attached. Although I will have a monitor connected to this device at the show showing a full RISC OS desktop with both SatNav and RiscOSM running, the unit is designed to provide sufficient information on an OLED display and an optional electronic-ink display.


The box is now pocket-sized.


The box is now quite a bit smaller.


A trip from Bristol to Milton Keynes was recorded using SatNav in GPX format and then passed to RiscOSM for analysis. The logging included information in the format below:

<trkpt lat="51.48479185" lon="-2.612334261"><time>2017-10-06T09:18:18.56Z</time><extensions><satnav:odo>2183</satnav:odo><satnav:dxy>10/26</satnav:dxy></extensions></trkpt>
<trkpt lat="51.48522501" lon="-2.611908333"><time>2017-10-06T09:18:29.00Z</time><extensions><satnav:odo>2240</satnav:odo><satnav:dxy>29/48</satnav:dxy></extensions></trkpt>

Development

The development of this project has been described in Archive magazine:

At the show you can see that a power boost board has been added to extend battery life, software-controlled power switching has been added (either using 'on' and 'off' push buttons or a Witty Pi and real time clock/alarms) and GPX logging has been added to internationalize Satnav, now at version 1.90.


The power boost board allows an internal 3.3V LiPo battery to be float charged by an external 5V powerbank or mains adapter. It produces an output of 5.2V from either the internal battery (3.3V) or the external power supply (5V), whichever is the higher voltage and will float charge the internal battery from the external source. If the internal battery becomes discharged or the external ENABLE line goes low, the unit will turn off.


The power control circuitry on the ProtoPAL board. The ‘on’ and ‘off’ buttons cause q and /q to change state. The ‘on’ button forces /q to go high (provided the ‘off’ button is open circuit, q will then stay low forcing ENABLE high). This turns on the power. During the boot process GPIO 4 is set to active output high. Holding the ‘on’ button down causes GPIO 19 to be low (which can be read by software, for example to download the log) and will light the LED if Vs is 5V - i.e. if there is an external power supply connected.
The ‘off’ button forces q to go high (provided the ‘on’ button is open circuit, /q will then stay low, which can be read in software via GPIO 26). With q high, this allows GPIO 4 to control the ENABLE signal: unless GPIO 4 is active output high, ENABLE will go low, turning off the power.
Once the ‘off’ button has been pressed, GPIO 26 will remain low, will be read by software, logging will be completed, the displays updated and a shutdown/restart cycle will be initiated. This updates the CMOS ‘last on’ time so that any subsequent start up will be with a time and date no earlier than this. The restart cycle resets the ROM modules, returning GPIO 4 to inactive and thus removes the power.

Making the breakout board is a bit fiddly. The first step is to wire up the board and test for shorts:


then carefully solder on the 74HC00 chip:

The ProtoPAL board now plugs onto a Pi model A+ and has a header for a PaPiRus display. Five flying leads, plus power and ground, are then soldered as in the diagram below:

the wiring diagram for the ProtoPAL board.

And just when I thought I had finished, the ProtoPAL board is discontinued. So here it all is again on a smaller breakout board. First solder on a few wires:

Then a few more, finishing off with a few diodes, resistors and a 74HC00 chip:

so that it looks like this design layout:

and here it is, fully functioning:

it has magnetic feet, a PaPiRus display on top, with OLED and GPS module on the front face.

a view from the rear, showing the power meter, sockets for USB, HDMI and a mains adapter or supplementary powerbank and the 'on' and 'off' push buttons.

A simpler and smaller unit without the power meter and the PaPiRus display. Is this the smallest RISC OS portable? The battery life is over 12 hours in a case 90mm x 60mm and 50mm high.

Testing the small unit in a short car trip shows the unit acting as a speedometer. The NMEA sentences it uses to derive its position are also shown - the demonstartion is running at about the correct speed with updates about every 2 seconds (the NMEA data are updated every 2s). The serial data arrive with no handshaking so occasional errors occur - thus the display may occasionally blank out (as it will have no new NMEA data to log and thus think it is lost or in a tunnel).

What you would see if you had RiscOSM running as well as the unit showing the speed on an OLED display. NMEA messages are also shown but you would not normally see these.

Loading the 'gpx' file log from the unit and analysing it in RiscOSM gives the results below:

RiscOSM 1.45 analyses the log file for the journey but speeds are a bit spiky.

RiscOSM 1.50 analyses the log file for the journey much more accurately now.