Serial Data received from Commercial Geiger Counter - feasible arduino logger?

Projects General Guidance
1

Hello All,

I am very new to programming but have been slowly reading and talking to friends and am starting to get an idea of using an arduino for various things.

I have an idea for a project and i wonder if those that are more knowledgeable than me could advise as to feasibility of creating this.

I have an Automess 6150AD-4 geiger counter - a commercially made german radiation detector. It displays the radiation readings on a LCD screen and also outputs the data as binary. The meter acts purely as a transmitter, and outputs the strings exactly 1.049seconds apart and a new string always starts with '02' as demonstrated below.

The automess outputs at 4800baud, 8 bits, no parity, 1 stop bit, and i captured this data on the CoolTerm program on a macbook using a USB-Serial adaptor)

02 14 E2 55 FE 5D
02 14 32 53 FE 8B
02 14 98 50 FE 22
02 14 13 4E FE B7
02 14 A2 4B FE 03
02 14 44 49 FE E7
02 14 F9 46 FE 55
02 14 C1 44 FE 6F
02 14 9B 42 FE 33
02 14 85 40 FE 2F
02 14 02 7D FD 96
02 14 19 79 FD 89
02 14 20 44 FE 8E
02 14 FF 41 FE 54
02 14 DE 7F FD 48
02 14 DE 7B FD 4C

The manufacturer has been very helpful and sent me the technical manual for the output, complete with a QBASIC code for decoding the string. A friend has re-written the string in C for me. The string contains the information of the meter type, and the dose rate.

My plan is to make a Data logger that plugs into the GM counter to log this output, and to tie it to a GPS reading.

All i want to capture is the radiation reading, the GPS location and a time stamp.

The ports of the device i am using to capture that data is GND and Tx, so my plan is to use UNO WITH a TTl to RS232 adaptor, an SD/GPS shield and package it up in a box with a battery (the 6150AD4 also outputs 4.5v which i will explore in future for a power source using a nano and micro SD etc, but for now - UNO and external power)

  • step 1 is get the Automess talking to the arduino, and the arduino logging the binary data to a plain SD card shield

  • step 2 is then to layer in GPS shield and get that logging with the binary data

  • step 3 is to work out how to decode the binary on the arduino so it logs the data as a readable text. (no idea how to do this!)

It is step 3 i am unsure about to be honest, and i am not yet convinced about step 2 either.

Below here is the QBASIC from the manufacturer for decoding the string. I sent them my data grab and they verified it is correct, but left the decoding up to me. I also attach the manufacturers instructions they sent

Any suggestions or comments on this idea welcome,
thanks
Ed

​' 	Variable Types 

DEFINT A-W
DEFSNG X-Z
' Constant Expressions 
CONST STX = 2 
CONST DEVERR = 57 
'--------------------------------------------------------------------- 
'Main Program
'--------------------------------------------------------------------- 
' Open COM: 4800 Bd, no parity, 8 data bits, 1 stop, no handshake
OPEN "com1:4800,n,8,1,rs,cs,ds,cd" FOR INPUT AS #1
ON ERROR GOTO RecvErr
' Main Loop: read and decode string (6 characters including STX), 
'  display result, exit on any key. 
MainLoop:
DO
WHILE ASC(INPUT$(1, #1)) <> STX: WEND   'wait for STX
sonde = ASC(INPUT$(1, #1))           'type of detector/6150AD
bc = sonde
mantlo = ASC(INPUT$(1, #1))          'low order mantissa
bc = bc XOR mantlo
manthi = ASC(INPUT$(1, #1))        'high order mantissa
bc = bc XOR manthi
expon = ASC(INPUT$(1, #1))        'exponent
bc = bc XOR expon
IF expon > 127 THEN expon = expon - 256 
bc = bc XOR ASC(INPUT$(1, #1))           'block check
IF bc <> 0 THEN ERROR DEVERR                  'block check error
mant = manthi * 256 + mantlo                       '16 bit mantissa
xdl=mant*2 ^ (expon - 15)                     'dose rate as floating point number
GOSUB GetProbe 'set ger$, det$ and unit$
PRINT TIME$; " Device: 6150"; ger$; " Detector: "; det$;
PRINT USING " Reading=########.### "; xdl;
PRINT unit$ 
LOOP WHILE LEN(INKEY$) = 0 'exit on any key
PRINT "End."
END 
'--------------------------------------------------------------------- 
'set ger$ / det$ / unit$ according to 'sonde' 
'--------------------------------------------------------------------- 
GetProbe:
flag$ = ""
IF sonde >= 128 THEN flag$ = "/E": sonde = sonde - 128
ger$ = "AD2/4/6" + flag$
IF sonde >= 64 THEN ger$ = "AD1/3/5" + flag$: sonde = sonde - 64 
det$ = "unknown"
unit$ = "μSv/h"
SELECT CASE sonde 
CASE 0
det$ = "Probe AD-0"
unit$ = "cps" 
CASE 7
det$ = "Probe AD-b"
CASE 15
det$ = "Probe AD-15"
CASE 17 
det$ = "Probe AD-17"
unit$ = "cps" 
CASE 18 
det$ = "Probe AD-18"
CASE 19 
det$ = "Probe AD-19" 
unit$ = "cps" 
CASE 20 
det$ = "internal GM"
CASE 21
det$ = "AD-t low DR"
CASE 22 
det$ = "AD-t high DR"
END SELECT 
RETURN
' --------------------------------------------------------------------- 
' Handler for transmission errors
' --------------------------------------------------------------------- 
RecvErr:
IF ERR = DEVERR THEN PRINT TIME$; " Transmission Error": RESUME MainLoop 
ON ERROR GOTO 0

ADBUCHSE.pdf (132 KB)

2

The ports of the device i am using to capture that data is GND and Tx, so my plan is to use UNO WITH a TTl to RS232 adaptor, an SD/GPS shield and package it up in a box with a battery (the 6150AD4 also outputs 4.5v which i will explore in future for a power source using a nano and micro SD etc, but for now - UNO and external power)

Some of what you plan sounds achievable.

You should not need the TTL to RS232 adaptor because the signal from the device is only 4.75V, so can be read directly by the Arduino.

Not sure what you mean by using the Tx port of the "capture device" (presume a serial-usb adaptor). Would have thought you should be using Rx.

The 4.75V output from the Geiger counter can only source 50mA. That's only just enough for an Uno. SD cards and GPS receivers use quite a lot more. You may not be able to power your device without an extra battery.

I would recommend an Arduino with extra available hardware serial pins. Uno only has one and that's connected to the usb, so you would be forced to use software serial for both the Geiger counter and the GPS module, which may cause some problems. Arduino Mega has several available but Mega is even bigger than Uno and you have no use for all those other pins... In any case, neither Uno nor Mega is a good choice for a portable, battery powered circuit. Fine for prototyping on the bench.

3

PaulRB:
You should not need the TTL to RS232 adaptor because the signal from the device is only 4.75V, so can be read directly by the Arduino.

But, you need to invert the signal before it is fed to the serial port (UART/SUART) of the Arduino.

x1z.png

x1z1.png

x1z.png

x1z1.png

4

If your friend has already translated the QBASIC program into C, you should be able to use that code in an Arduino sketch with a little tweaking.

5

GolamMostafa:
But, you need to invert the signal before it is fed to the serial port (UART/SUART) of the Arduino.

I was thinking there was an option in Serial.begin() for an inverted signal, but there isn't, so yes, you will need to invert.

wildbill:
If your friend has already translated the QBASIC program into C, you should be able to use that code in an Arduino sketch with a little tweaking.

If it is a PC variety of C, maybe quite a lot of tweaking! Please post the C translation. But this time please use code tags so your code looks like this.

6

Perhaps not the easiest boards for a complete beginner to start with, but maybe consider a MKR ZERO. These have an SD card built-in and the SAMD processor can be configured to provide extra hardware serial ports. There is a MKR GPS shield that should be compatible. I've never used either of those myself, but I have used Arduino Zero compatible boards.

7

PaulRB:
I was thinking there was an option in Serial.begin() for an inverted signal, but there isn't, so yes, you will need to invert.

If using SoftwareSerial.h Library, then the option for inverted signal is there (I have never tried).
sscons.png

8

GolamMostafa:
If using SoftwareSerial.h Library, then the option for inverted signal is there

Ah, that must be what I was remembering, thanks.

But as I said earlier, I'm not sure I would recommend using software serial for this project, because there will be two sensors sending data over serial asynchronously, and the Arduino won't be able to receive from both simultaneously if software serial were used, and so data would be lost. If some lost data is acceptable, it might be ok to use software serial. As both sensors will be sending updates every second or so, it might not be important to record every reading, in which case the Arduino could alternately read each sensor.

@Flat4 what data rate do you need to log? i.e. how many readings per minute or hour. Could there be short spikes in the Geiger counter readings which would be important to detect, meaning every reading from the sensor must be captured and none lost?

9

As to softwareserial, I've seen a snippit like below for inversion. Never tried it. The below pix shows a simple serial inverter circuit. One can start converting the data testing just using the serial monitor.

SoftwareSerial modem(10, 11, 1);

ezservo.jpg

ezservo.jpg

10

PaulRB:
Some of what you plan sounds achievable.

You should not need the TTL to RS232 adaptor because the signal from the device is only 4.75V, so can be read directly by the Arduino.

Not sure what you mean by using the Tx port of the "capture device" (presume a serial-usb adaptor). Would have thought you should be using Rx.

The 4.75V output from the Geiger counter can only source 50mA. That's only just enough for an Uno. SD cards and GPS receivers use quite a lot more. You may not be able to power your device without an extra battery.

I would recommend an Arduino with extra available hardware serial pins. Uno only has one and that's connected to the usb, so you would be forced to use software serial for both the Geiger counter and the GPS module, which may cause some problems. Arduino Mega has several available but Mega is even bigger than Uno and you have no use for all those other pins... In any case, neither Uno nor Mega is a good choice for a portable, battery powered circuit. Fine for prototyping on the bench.

thanks for the reply,

Sorry i meant the port of the device i am receiving data from only (for my purposes) uses GND and Tx, i will receive the data on an arduino

Noted about the 4.75v - i will power the logger externally then, no problem.

As for the Serial ports, i will look into other devices to proto it i think, SoftwareSerial sounds okay, and to be honest dropped data now and again isnt an issue

11

PaulRB:
I was thinking there was an option in Serial.begin() for an inverted signal, but there isn't, so yes, you will need to invert.If it is a PC variety of C, maybe quite a lot of tweaking! Please post the C translation. But this time please use code tags so your code looks like

this.

wildbill:
If your friend has already translated the QBASIC program into C, you should be able to use that code in an Arduino sketch with a little tweaking.

thanks guys, see attached C code, posted as requested - sorry about that :slight_smile:

void AutomessHandler(char* AMSTRING){
         int MHI, MLO;
         double MANT,DL, EXP1;
         //float     EXP1 ;

             // Data From Automess.
           MLO = AMSTRING[2] ;
           MHI = AMstring[3] ;
           EXP1 = AMstring[4];
           DL = 0;
           MANT = 0;
           Check = 0;
           ChecksumGood = 0;

           if(EXP1 > 127){
            EXP1 = EXP1 - 256;
           }
           MANT = (MHI * 256) + MLO;

           EXP1 = EXP1 - 15;

           DL = MANT * pow(2.0,EXP1);
           //------Slimline power function doesn't work------------------
           /*DL = 1.0;
           for(i=0;i<2;i++){
            DL *= EXP1;
           }
           DL = DL * MANT;*/
           //------------------------------------------------------------
           AUTOMESSUSV = DL;

           for(i=0;i<4;i++){
            Check = Check ^ AMSTRING[1+i];   //EXOR up all bytes
           }
           if(check == AMSTRING[5]){         //Compare to Checksum
            Checksumgood = 1;
           }



}
12

PaulRB:
Ah, that must be what I was remembering, thanks.

But as I said earlier, I'm not sure I would recommend using software serial for this project, because there will be two sensors sending data over serial asynchronously, and the Arduino won't be able to receive from both simultaneously if software serial were used, and so data would be lost. If some lost data is acceptable, it might be ok to use software serial. As both sensors will be sending updates every second or so, it might not be important to record every reading, in which case the Arduino could alternately read each sensor.

@Flat4 what data rate do you need to log? i.e. how many readings per minute or hour. Could there be short spikes in the Geiger counter readings which would be important to detect, meaning every reading from the sensor must be captured and none lost?

so, the occasional bit of missed data wont matter, if its logging the data every second.

In terms of short spikes - no - the rate of data transfer remains the same but the dose rate figures transmitted within the binary code will go up and down as necessary, the data transfer rate is faster than the averaging time of the automess meter so that doesnt matter, as long as most readings are captured, the odd dropped reading wont hurt. This is only a hobby project aswell, not a safety related project.

Reading alternate sensors would be fine, that would work and be totally acceptable. I dont really need to log every reading every second, logging every 5 or 10 seconds would be fine and would still work for my purposes.

thanks for the replies

Ed

13

sorry one other question,

can i use pins 1+2 for the serial RS232 adaptor if i am NOT using the USB interface?

My intention is once the sketch is uploaded, then it will be a standalone device, and to read the data on my computer by taking out the SD card and putting it in my mac card reader.

means i wont be able to use Serial monitor when uplaoding sketches etc to debug, but would it work later when not attached to the computer?

thanks

Ed

14

OKay

I have managed to get the Automess meter to talk to the Arduino, i did what was suggested above by omitting the TTL-RS232 converter as the Automess only puts out 4.75v, rather than 12v of RS232, i connected the GND pin to GND on the arduino and the Tx pin to Pin 8 on the arduino which i set as Rx

I gave me something i didnt understand in the serial monitor at first, that didnt match what i had got prior on the Mac terminal program. Was a bit confused but then i inverted the SoftwareSerial as Zoomkat suggested and that gave me raw data in the Mac terminal that looked the same as what i had got before so thats good.

This is the Hex from the terminal program BEFORE i inverted the logic, and using serial.print

BF DD 8A 05 31
BF DD DB 55 31
BF DD DA 3A 17

etcetera.

then i inverted the logic and got this:

02 14 AF 64 FB 24
02 14 88 61 FB 06
02 14 7B 5E FB CA

So thats good, direct connecting to the Uno and inverting the logic gives me what i was expecting to see.

Serial Monitor looks different though, using serial.print i get:
22 02 27 74 25 36

but if i use serial.write i get ASCII characters (i think?) but the the terminal program i was using doesnt look the same. so i dont know.

Here is the code i used which i just pulled from examples and changed slightly.

#include <SoftwareSerial.h>

SoftwareSerial gtSerial(8, 7, 1); // Arduino RX, Arduino TX

void setup() {
  Serial.begin(4800);    // serial / USB port
  gtSerial.begin(4800);  // software serial port
}
byte rx_byte = 0;        // stores received byte

void loop() {
  // check if byte available on the software serial port
  if (gtSerial.available()) {
    // get the byte from the software serial port
    
    rx_byte = gtSerial.read();
    Serial.print(rx_byte);
  }
}

Still feels like a step in the right direction, any suggestions welcome!

thanks

Ed

15

Flat4:
Serial Monitor looks different though, using serial.print i get:
22 02 27 74 25 36

#include <SoftwareSerial.h>

SoftwareSerial gtSerial(8, 7, 1); // Arduino RX, Arduino TX

void setup() {
  Serial.begin(4800);    // serial / USB port
  gtSerial.begin(4800);  // software serial port
}
byte rx_byte = 0;        // stores received byte

void loop() {
  // check if byte available on the software serial port
  if (gtSerial.available()) {
    // get the byte from the software serial port
   
    rx_byte = gtSerial.read();
    Serial.print(rx_byte);
  }
}

That output is not produced by the posted code.

Why do you compare HEX to DEC and then decide that it is different? (looks different...)

Why do you think you would have to use 4800 baud to the computer?
You generate twice(+) the data you receive,
do you think blocking on the hardware serial will help running a software serial?

16

Whandall:
That output is not produced by the posted code.

Why do you compare HEX to DEC and then decide that it is different? (looks different...)

Why do you think you would have to use 4800 baud to the computer?
You generate twice(+) the data you receive,
do you think blocking on the hardware serial will help running a software serial?

Thanks for the reply, appreciated,

What should be produced by that code?

I was going on what i was seeing in the serial monitor, and a terminal program, and comparing to a USB - RS232 converter i already had. The data starting '02' the company told me is the correct format . I am getting different things between serial monitor and the terminal program, but i dont know why though.

The automess geiger counter i am reading from outputs at 4800baud and thats fixed, i cant change it so need to receive it at 4800baud on the serial port?

I dont know, would it? happy to try, but not sure how.....

sorry

Ed

17

i will grab some screen grabs later

18

I think the point that was made earlier is that you could increase the baud rate between Arduino and PC, for example to 115200. Serial and gtSerial don't have to be the same speed.

What I don't get is how you can be seeing different output on the serial monitor Vs some other terminal program. They are displaying the same data, or should be. What terminal program are you using and are you using any special feature it has?

19

Aah okay, didn’t realise they could be different speeds. Will try different baud rates.

I am CoolTerm on Mac (OS Catalina), will see if I can get another terminal program to try.

Also I found this thread, seems to be trying to achieve the same communications I am - I need to read the whole thread a couple of times to absorb it I think

https://forum.arduino.cc/index.php?topic=590774.0

Will double check the pin out of the automess aswell, and check I made the automess to DB9 connector correctly (I have only wired pin 2 and pin 5 of the DB9 as as far as I can see that’s all the Automess uses)

Thanks for your input

Ed

20

Oh and on coolterm on the Mac I just have it set to send the raw data