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: http://noctis.de/ramblings/linux/49-howto-fixed-name-for-a-udev-device.html 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 http://wiki.freepascal.org/Executing_External_Programs#Run_detached_program 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.