This one is more notes to me, but someone may find it handy.

First up getting the test suite on this tracker/remote control system was not as clean cut as it should have been. Turns out Lazarus sockets doesnt do DNS so you cant just call a hostname, rather than bombing out with an error it just hard locks or ocasionally segfaults. TWSocket can handle this and as I want to get as close as possible I think there is going to need to be a wrapper around this. I also think a TpersistantSocket may be of uses where the socket has a FIFO and will attemnpt to reconnect on loss. Much thinking on this.

Next up, hours lost trying to work out why Traccar wont talk to the diag software when it was up, turns out that I discovered two things. Firstly, had I looked at the NMEA spec and paid attention I’d have seen that the spec uses * as a reserved char for the checksum and it isnt supplied in a new field as I was doing. This was leading to a ‘,’ being added to the ID and Traccar (being helpful) Silently bins it and the packet. Traccar is going to be going under the knife when this is all done. Secodnly, nothing in the world either a) agrees on how to make a checksum and b) actually uses it so it can be ignored. Traccar assumes its garbage and bins it. Save yourself some work when coding for the T55 protocol and dont bother.

Next up, PPP

Loads of tutrials on how to make this work, how to talk to the SIM900/908 and none of them seem to work. I had this workin before I wiped the SD card annoyingly so back to work. I ended up using PPPConfig in the end, WVDial doesnt seem to like these modems and indeed, wont detect them. Most PPP configs almost work failing with errors that no one have ever seen SO FrankenPPP was born. I’ll pop the details up later because I know others are trying to do this. In short, run through PPPconfig and then trash the resultant CHAT file, its broken, something in there makes the SIM900 fall over with an odd error message. Its likeley a CRLF where it shouldnt be, a missing ‘ or something I just couldnt see. Roll your own or use the one I paste and all will be well.

Next up, default gateways. Theres a touc of open source snobbery going on here. ‘Unable to Replace Default Gateway’ will be in your logs and nothing will work. Ask online and the standard response is ‘Yup thats right BECAUSE YOU ARE AN IMBECILE AND HAVE A DEFAULT GATEWAY!’

Thats all the help you are going to get.

Not helpful, you see MOST boards are going to be setup like this and this unit will be chipped and changed from LAN to WAN frequently so this needs fixing. I havent looked at the scripts yet but there are up and down scripts. Firstly I need to drop a semaphore anyway to give me the interface state but also this is a good place to fix this gateway issue. O2 (whom I dont reccomend for this) use Private IP addresses for their network (3 and EE dont for sure) so be aware of this. Do an ifconfig and see what gateway ppp0 is giving.  For me it was 192.200.1.21.

Run a terminal and these two commands will fix it…

sudo route del default
sudo route add default gw 192.200.1.21 ppp0

This now means all will go out the PPP interface. Now this isnt helpful when it all falls on its face so when you are done do it again to make it right for your network again (I’m 99.0/24):

sudo route del default
sudo route add default gw 192.168.99.1 eth0

Having been out and tested this it seems that this default gateway silliness is caused by DHCPCD, however its entireley correct as you’ll want to get on the net and play about while you are working and thus you need this route here. However if the board isnt plugged in, DHCPCD doesnt even try, thereis no default route and PPP behaves as it should. It now makes me wonder if I even need to do this and shouldnt just make a script for when I’m in dev mode.

These should go in the PPP up and down scripts, but I’ve not gotten there YET

I’ve been asked to look into a tracking and dispatch system for a customer. Now those of you that know me/my company know that we’ve done this on a number of ocasions, the most recent version being Touchdown’s Mesopod system.

All of these units have used dedicated functional units to do each step, a GPRS Modem , A Firewall/router (The pod combines these), and a client device. Now for this one we are going to try something different…..Its all going in one unit.

The design breif we have pulls in a lot of old tech for us, GPS, 3/4G networking, Sensor systems, Chassis electrical interfaces, message passing and databse applications, in that lot there is no scary new ground. Its the client.

A typical system like the Mesopod uses a BSD/Linux based Firewall system. Off the shelf, free and pretty simple. We’ve not bothered ourselves too much with this, it’ll also look after the VPN back to base and in the past its almost always been an Atom based unit of some kind. The Client? Win XPe, the only version of XP tht we can still use. But it all works. We have a huge toolbox of apps for sharing GPS units, grabbing data from our boards, providing multiple serial streams and so much more. Theres only one big problem…We are going ARM on this one.

This means we have a problem, in fact, a very large probelem. SO what software in our toolbox to we have to use here…erm, stuff all. Thats right girls and boys we have NOTHING and worse, theres pretty much nothing off the shelf we can use either.

This isnt as bad as it seems to start off with. You see the first step is we will be using Debian Linux. Right off the bad I can talk to the display, anything I need to hang off of I2c, databases, the GPRS modem, touchscreens, GPS modules, ethernet etc so thats a HUGE swathe of work done. As a comparison the last time we used ARM we programmed it in assembler/C and just getting the touchscreen up took a few days. Here I had the target system up and browsing the net in 30 mins. So the first part of this adventure is wiring everything up and making it all talk, I can do that, I am good at that…

Now the trick is going to be more scheduling and priority, learning how to break other peoples code and ah yes, I do need to write a little of our own for the client too. I’ll be using Chassi s interface boards I already designed to find out whats going on with the veichle and to turn things on and off. I will need to write drivers for this and I’ll need to find another serial port as I’m going to be using the ones I have already, in fact I already have a board of FT232’s in my minds eye.

Its going to be a bit of a challange. The idea is to end up with a nice small box and a 7/10″ touchscreen that chatters away to the head office and can talk to GPSGate server niceley too and just tie up all the bits niceley. Its also going to be our first project with any amount of Linux coding involved so that will be fun too 🙂