Promiscuous Ports, Power and unstable PPP

Well the tracker system went out on the road earlier and it was an unmitigated disaster. Mainly due to power issues, the PI2, relay board, controller board, GPS, IMU and GPRS board draw a fair bit of juice, and its more than the poxy USB charger can supply. I’m frankly not that surprised.

It highlighted that it doesnt take that much to start making things trip up power wise, the system does have power monitoring and I may start looking towards some more intellegent form of power management. On top of that automotive power is dirty, its ful of noise and spikes and you can only gurantee it’ll be somewhere between 11V and 15V which isnt good for electronics. Add to that a 20 year old dirty cigar lighter socket, a cheap chineese PSU running at/above its limit and all hell breaks loose. First up then we need to get things cleaned up. I have a sketch for a PSU on my desk but that needs refining as it’ll form part of a new board to replace a goodly chunk of the wiring. For now I’ve gone over to a 2A LM2596 switching regulator module and thats helped with supply stiffness and clenliness. Behind this are two nice reservoir caps, enough to give everything about a second of power to cover brown outs. Its possible I may need to look into batteries however the final unit should be wired to the battery directly which should protect it from load shedding devices on crank over. Ideally I’d like the M25012 to hold the power to the Pi off till it knows all is well. The system now supplies the power for the monitor as well and has the ability to isolate it, this should help,

Next issue, the bloody TTY’s keep moving. It seems that unlike Windows USB devices are always installed in the order they are found, every time, Windows remebers where a device is and all is well, for example, plug in two USB com ports and windows will splat them on COM3 and COM4, every time those devices are in those USB ports they will from henceforth ALWAYS get those IDs. Linux, or at least Rasbian, doesnt. It seems to assign them on first come fist served basis which means that its luck of the draw if you get ttyUSB0 for the first device or ttyUSB1. Moving any USB device around before a reboot seems to muck this up and this isnt helpful.

The answer seems to be here: although note that udevinfo is actually a symlink whereit exists and it wont work on Raspbian, you want udevadm info instead 🙂 Its also possible to use PID/VID and serial numbers to do this. Now as the final will use either a hub and 4 devices OR a single 4 port I’m anticipating further pain with this 🙁 However for now the bridge and GPS adaptor use different VIDs and PIDs so the following works :

tail -f /var/log/messages and plug each device in, make a note of the PID and VID (they are displayed)

sudo nano /etc/udev/rules.d/51-usbserial.rules and add:
KERNEL==”ttyUSB[0-9]*”, ATTRS{idVendor}==”1a86″, ATTRS{idProduct}==”7523″, SYMLINK+=”trnet0″, GROUP=”tty”, MODE=”0600″
KERNEL==”ttyUSB[0-9]*”, ATTRS{idVendor}==”067b”, ATTRS{idProduct}==”2303″, SYMLINK+=”sgps”, GROUP=”tty”, MODE=”0600″

You can see where the PID and VID need to go. Save, exit and unplug everything. Once you plug them in the symlinks you chose (In my case trnet0 and sgps will be created in /dev. These simlinks will always point to these PID and VIDs. Now with identical devices this wont work, there are other ID’s you can use such as serial number although these need to be programmed using the vendors utility.

PPP works but there are some issues. Nameley right now we dont know if its up or down. I need to work out a way to deal with this and maybe some scripting to keep it up. I have now worked out how to get control of PPP and know what is going on. First starting and stopping are easy. Make sure your application is running with priviliges to be able to do this, adding the user to the ‘dip’ group should be enough. Then you can use to run pon and poff. To specifiy the profile use process.addparameters.add(‘<profilenamehere>’); and normally you’ll be wanting to run /usr/bin/pon or poff.

Next up modify /etc/ppp/ip-up. Before the line PPP_TTYNA ME=… line add:

echo $4,$5 > /tmp/pppup.sem
chown pi /tmp/pppup.sem

The chown assigns access to the pi user, you could give the rights to anyone. Now once PPP comes up pppup.sem will be dropped in /tmp/ the $4 and $5 will mean the file contains the local IP and gateway IP seperated by a comma.

In ip-down add the line rm /tmp/pppup.sem in towards the top and this will remove the file when the link goes down.

It may be worth removing this file if present at boot as a crash/power failure may leave it behind.




Tracker Troubles

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

Run a terminal and these two commands will fix it…

sudo route del default
sudo route add default gw 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 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