PyRadmon install and set up on Raspberry Pi (Wheezy Raspbian)

Looking to run the code on a Beagle Bone Black. I'll let you know the outcome as I get the system up and running.

Working! I need to kill it now and setup the Bone to run standalone with the detector and remove the display, keyboard, etc...

Well I had an older Beagle Bone Black that I used for this. Not sure of the REV of the board but believe it is a B or C. In either case I upgraded to Debian Linux with this version:

https://rcn-ee.net/rootfs/bb.org/testing/2015-02-01/lxde-4gb/bone-debian-7.8-lxde-4gb-armhf-2015-02-01-4gb.img.xz

A fairly recent build that is put on the Micro SD Card. I tried a number of earlier builds and had various configuration issues or missing pieces. This image takes up a 4GB card so use something like a 8GB card to give you some room for later use.
Once it was running I then expanded the image to allow for the use of the whole SD card. I am running a 32GB card so I have tons of space now!
How to expand the image to the size of your card --> http://inspire.logicsupply.com/2014/06/expanding-file-system.html

Once installed then I ran an update as defined on page one. I also applied the Python Audio even though my setup didn't require it. I ran the application and it did create the config.txt file properly. I edited it and applied the user/passwd and config settings. My GMC unit runs at 57600 Baud. That is very high for a serial interface. The PyRadmon app will start up and run fine for about two minutes and then I get an error:

Reading configuration:

User name configured

Password configured

Serial port name configured

Serial port speed configured

Protocol configured

Device number configured

Protocol configured


Using GMC protocol for 1 => geiger 1

No samples in queue, waiting 5 seconds => geiger 1

Gathering data started => geiger 1

Initializing GMC protocol communication => geiger 1

Found GMC-compatible device, version => geiger 1: GMC-300Re 2.36

Please note data will be acquired once per 5 seconds => geiger 1

Unit shows time as => geiger 1:

<SETDATETIME[150213224037]>>
No samples in queue, waiting 5 seconds => geiger 1

Geiger sample => geiger 1: CPM = 1 2015-02-13 22:40:41.201395
Geiger sample => geiger 1: CPM = 1 2015-02-13 22:40:44.708220
Average result => geiger 1: CPM = 1 2015-02-13 22:40:44.708220

Connecting to server => geiger 1

Sending average sample => geiger 1: 1 CPM

Server response => geiger 1: HTTP/1.1 200 OK

Waiting 30 seconds => geiger 1

Geiger sample => geiger 1: CPM = 2 2015-02-13 22:40:48.218432
Unknown response to CPM request, device is not GMC-compatible? => geiger 1


I think I will try lowering the baud rate down. The BBB may be struggling with the full X-Windows/mouse/keyboard/HDMI interface and 57K baud communication! I will lower it down to 9600 baud and see how it works. I plan to run the board with only a ethernet cable, the GMC unit, and a power cable. I will launch and setup the unit through the USB device interface and SSH. I'm still new with the BBB but I assume I can setup the OS to auto-launch the PyRadmon so i would not even have to SSH into the board to launch it.

Update: Looks like I can not easily reset the baud... Also the data above I had just reset the detector so the counts were really low. Normally they are in the 20's to high teens.

I see, and yeah the baud should be low, these devices and the script are not made to run on image-flashing rates.
They don't have the proper handling for such speeds.
9600 is right on the sweet-spot for both the devices and the script.

I hope you will get it to work.
And I had the rate issue as well on a Cisco router console port, took a while to get it back, had to force it down to 9600 to get rid of the gibberish text I got.

Well no luck on trying to slow down the detector. Only solution is to hook it back to the PC or get a different detector that can be slowed down. My GMC-300 has a fixed baud rate and that appears to be the problem. I have played with various settings in the BBB and still not working. The longest I can get it to work is about five minutes until a communication error eventually takes it out. I am going to try a protocol analyzer to see what the GMC thinks it's sending back. Based on that I can tell if it's having trouble with reception or if it's a command written to the unit. The Python script appears to be looking for two bytes returned for CPM. If it does not get the two bytes then it fails.

Command: <GETCPM>>

Return: A 16 bit unsigned integer is returned. In total 2 bytes data return from GQ GMC unit. The first byte is MSB byte data and second byte is LSB byte data.

e.g.: 00 1C the returned CPM is 28.

Firmware supported: GMC-280, GMC-300 Re.2.0x, Re.2.10 or later

I have tried to set the check to >=1 and it works for a while as well. i believe it's an issue with the command written and just not just the data coming back insufficient.