Science/Engineering/Technical forums

Here's what I've come up with so far for the new cool toy. This is all in perl, and meant for linux, though you can make it run on windows if you install perl, some modules (and an edit for serial port module name), gnuplot, and the GTK runtime, all available, but it multiplies the effort considerably, and I run linux here anyway, being more or less in love with the Mint distribution and the Mate desktop, which is a fork of gnome 2 - that works right. I don't need my desktop to look or work like a phone or tablet, so I ditched Ubuntu awhile back. Version 17.1 of Mint even has compiz (rotating cubes of desktops and other frills) and it even works right. Stable and all that.

Here's the paydirt: There is one small problem, that shows up in different ways in both windows and linux. That that there are no real serial ports anymore, and no standard way to assign a USB<>serial dongle to either a com port or a tty???.
Therefore, I used a trick for linux that doesn't exist in windows at all - when you plug in a serial dongle in linux, a directory is created: /dev/serial/by-id and in this directory will be a list of all the dongles with their factory serial numbers. Thus, if you dedicate one to whatever, you can always look in there, find the matching virtual filename, and pass that to the perl serial port module (Device::SerialPort in linux, Win32::SerialPort in windows). So, since there is zero chance you've got the same dongle AND opsys I have, you're going to have to edit this code a little, for grgrab and grspec (GRplot just works from files, so no worries, other than getting gnuplot (for either opsys) and the other junk you need for windows that linux comes with already.

grgrab is a command line program. You just say that to a terminal, and it finds the serial port (reports that) and goes into wait mode for you to tell the unit to dump its data memory. When done, it will ask you to hit <CR> to exit. No harm is done if you download the same things twice, other than to date stamps in the filesystem. It uses the unit time/date as a filename regardless, and always puts them in your "home" directory under a directory it will create called /GR130 if it's not already there.

This of course, makes it really easy for grplot (which does have a minimal gui for file picking) to find them for plotting. The unit can make three types of files, which get one letter extensions depending on what type they are, so the code knows what type of plot to do on them - the rest is completely automatic, autoscaled and so on, and with real units. This code depends on your having set up the unit for 1 second time resolution in survey mode, and 5 seconds and Sievert units in dose mode,
In both cases, those are the highest resolution modes anyway, and Sieverts are what we use in modern times for dosages.

Here are some screenshots: Once you invoke grplot, you get this for a GUI - just enough to leverage the system file chooser button to get to the files. While you can navigate that anywhere, it already knows to look where grbrab puts things. Choosing a file will result in a plot from gnuplot, perhaps like this one, where I started with nothing near the unit, then placed the Cs137 sample on there for a bit, then took it back off. The unit was in "dose" mode, and set up to save that data in its memory for later dumping via grgrab. Anyone needing to know how to edit the perl (it's pretty easy) need only ask me. You'd change which module to use for the serial port for windows, for example, and of course, where it looks for a dongle, change the name there. There is an example of autodetecting some of this in our standard counter software, but it's laborious to do that for every project, and still doesn't really handle the fact that different dongles will have different ID's in either the linux filesystem or the windows registry.
In either opsys, unplugging and re-plugging the dongle results in assigning it to a new com port of tty. The linux way is far better since you can just look for the hardware ID, which so far, no one has figured out how to do in windows. You just have to guess which com port every time...

grspec is the first version of all this, since the unit allows just dumping a single (the most recent, unsaved in it's store) spectrum. It might be handy for some use-cases, so I left it in the bundle. It only handles one chunk of data, and only does spectra, nothing else.

Here is the line you'll have to change in grgrab for linux machines. It's the id of what you see in /dev/serial/by-id/ when you plug in your own serial<>USB converter. I highlighted the virtual file name in the match, it's on line 42 of the code in the .zip above. Since that is a lot of typing to get right, what I actually do is this - look at the /dev directory with no serial dongles plugged in. When you plug in the one you're going to use for the GR 130, a directory will appear under /dev called /dev/serial (full path) and under that, /by-id. It will now have a virtual file with all the identifying info about your dongle. If you then right-click that file and select properties, you can select and cut-paste the long name into the code instead of the one shown here, which is only right for the one I own (and have taped onto the GR130 cable so I won't get them mixed up later).

For windows, it's a bit more complex...I'll address that later if asked, but you first need to use a different serial port module for perl, then use it a little differently. It's not my fault! There appears to be NO cross platform way to do serial ports, much less gui's that is seamless. In this case, it's a pain no matter the platform, just a different kind of pain. At least with linux, once you've got that magic long name, you're done and done forever. Had I used the defalut mapping to /dev/ttyUSB0, the software would fail if your USB detected another dongle first, or if you un and re plugged in this one. It's kind of a no-win situation. At least once this works, it always works. No guessing. No more changes later. It just works.

As far as we now know, there IS a way to dig into the windows registry and find some of this out, but the solution we used for standard counter doesn't fix all of the above objections every time. Such is life, perhaps a windows expert can tell us how to ID a given dongle for certain as to which com port it happens to be mapped to just now. I used to be one of those, but that was before XP...

I have done some slaving and brought forth this same (well, almost) code for a raspberry pi. Here is the install program: It's in .bz2 format, since that's what pi's can eat, they don't do zip without extra work.

Download this file, put it on the pi and extract it. Make sure the extracted grpiInstall is executable, then execute it. You can wipe it out and the .bz2 it came in anytime later.

This will create a /bin under your user directory (usually pi), and a GR130 directory where the grabber will put anything grabbed out of the GR130, and the plotter will look for files to plot.

Same caveats as above - I used a fixed ID from /dev/serial/by-id in grgrab to find the dongle that you're using for your GR-130, and yours will certainly be different - if only in serial number, probably manufacturer too. To keep things together and working here, I gorrila taped my USB<>serial dongle to the GR cable, so things would not get mixed up (dongles are cheap enough to dedicate one to this anyway).

To find your dongle ID, navigate to /dev in the file manager. If there are no USB dongles plugged in at the time, there will not be a /serial directory under this (yet). Make it so if you can - unplug any other dongles for the moment.
Now plug in the one for the GR130. Like magic, under /dev, a directory /dev/serial should appear. Under that will be two directories, /dev/serial/by-id (full pathname here), and by-path.
by-d is the one you want. Open that and a very strangely named virtual file will be there (that's your dongle ID). You can't directly copy/paste from the file manager, so right click and get "properties" and expand the window to the point where you can indeed select that long, nutty looking filename, so as to paste it into grgrab later (in any editor, I like geany for pi as leafpad doesn't have syntax highlighting, but suit yourself).

grplot here is *almost* the same code as for PC, but a glitch in pi's gladeXML support forced me to go to Tk instead. The install program does instsall all the perl modules required, gnuplot and so on - and gives you colorful messages while doing it.
It will take awhile...lots to download and compile, and the pi is no speed demon.

I strongly urge you to run
$sudo apt-get update
first. I had it built in, but man does it take a long time to run. You can run $sudo apt-get upgrade if you want to at any time - it *usually* works and usually improves things (so far, every time).

Then run the install. I'll get pinouts between the 1/8" plug needed for the GR and the db9 posted up here soon. I pulled a cable from a microchip dev kit and it just worked, so I haven't gotten out the ohmeter yet, but it's simple since there are only three wires, and obviously ground is the shaft of the 1/8" plug.

Another day, another cool thing. Glad to give Jerry a run for his money once in awhile

EDIT: here's your pinouts.
1/8" plug shaft - db9f pin 5
plug ring - db9f pin 2
plug tip = db9 pin 3

This is the case for all GR130 serial cables no matter the platform on the other end.

As is all too often the case, the first version of the pi code has a slight error, which I've since fixed. It was an off-by-one error in labeling the energy bins, not very serious most of the time, but hey, why not get it as perfect as the sensor?
So, here it is, fixed. FWIW, this only affects grplot and only the line that says "for i=3;i<256;i++ ... the three should be a two. So you could just as well simply edit grplot where it does the actual plot array setup and fix it there. I can't even claim the usual fencepost error, I simply mis-counted the bytes. The wonderful manual must have been written by a fortran programmer (could be, given the age and all). Those who have done this awhile will know what I mean - in fortran, arrays start with 1, not zero, like well, just about all other languages.

Sorry 'bout that. This one appears perfect.