Pi Persistence and a new link

Hi all. Sorry for no update last week as there really wasn't much to update. I have been persisting with the Pi and trying to understand the whole UDEV thing. I discovered I needed some additional 'packages' to allow certain things to be reported. Did this and ran one of the new commands 'udevadm' which was looking very hopeful when it started to hang the Pi. After much colourful language emanating from the study, I decided I needed to research this new development more. It would appear there is a known bug in the Pi whereby the output stack for this command running on the Raspbian OS fills up and then stops the Pi. Hopefully the Linux gurus can sort this out soon. Things like this happen with development boards such as the Pi. I'll keep a close eye on the Forums.

I stumbled on a new link as a result of my membership of MERG, the Guildford Model Railway Group (Sydney, NSW) who 'Wallerawang' as their current exhibition layout, but are planning their new exhibition layout (still early days) which they are hoping to possibly use MERG control for. A fellow MERG member is a club member and also a reader of this blog. http://www.gmrg.org.au/. I'll add this to my Links list.

The weekend just gone was the Brisbane Model Train Show and my club RMCQ was well represented. The lads looked very schmick in our new uniforms. Everyone was consistent. I was only able to get out on Sunday and help out.

So this week depending on the Linux gurus, I might progress with the Pi or not. As I mentioned to the above member/reader a for the Pi other people have been able to get JMRI running on it, as have I, but it is the integration of JMRI into the Pi as an access point in its own right that doesn't appear to be documented or experimented well at the moment, and that is what I am perservering with. That and the ability of the Pi to recognise some generic USB type conenctions such as the wifi dongle to be used as the access point, the NCE USB interface and the MERG USB interface that is keeping me busy trying to work it out. Hopefully the end result is some basic instructions whereby if these are connected the Pi will assign a more meaningful interface name than say /dev/ttyUSB0 to something like /dev/NCEUSB or similar. Then hopefully modellers who use other DCC manufacturers could potentially tinker with my instructions for their USB interfaces.

So if this doesn't move along at any speed I might look at starting some more modelling!