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

Whandall:
The missing comma behind ports changed the meaning of your sentence.

okay, you make a point.

You might want to start here:
Two ports receive

Here is a sketch that should be able to receive and sent to serial the raw data coming from the geiger counter. I haven't tested the inverse logic part of SoftwareSerial, so not sure if that works properly, and I'm not displaying the initial 0x02 (which is an ASCII STX start of text control character).

#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11, true); // RX, TX, invert signal

const unsigned long delayBetweenPackets = 1000u; //packet spacing in milliSeconds
const byte bytesInPacket = 5;
char receivedBytes[bytesInPacket];

boolean newData = false;

void setup() {
  Serial.begin(9600);
  mySerial.begin(4800);
  Serial.println("<Arduino is ready>");
}

void loop() {
  recvWithStartMarker();
  showNewData();
}

void recvWithStartMarker() {
  static unsigned long lastByteReceived = 0;
  unsigned long currentByteReceived;
  static boolean recvInProgress = false;
  static byte ndx = 0;
  byte startMarker = 0x02;// ASCII STX Start of Text
  byte rb;

  while (mySerial.available() > 0 && newData == false) {
    rb = mySerial.read();
    currentByteReceived = millis();
    if ((currentByteReceived - lastByteReceived) > (delayBetweenPackets / 2)) {
      //resync input if packet is not completed within allotted time
      recvInProgress = false;
      ndx = 0;
    }
    if (recvInProgress == true) {
      receivedBytes[ndx] = rb;
      ndx++;
      if (ndx == bytesInPacket) {
        recvInProgress = false;
        ndx = 0;
        byte checksum = 0;
        for (byte i = 0; i < bytesInPacket; i++) {
          checksum ^= receivedBytes[i];
        }
        if (checksum == 0) {
          newData = true;
          Serial.println(F("checksum correct"));
        } else {
          Serial.println(F("checksum error"));
        }
      }
    } else {
      if (rb == startMarker) {
        recvInProgress = true;
      }
    }
    lastByteReceived = currentByteReceived;
  }
}

void showNewData() {
  if (newData == true) {
    Serial.print(F("Packet received:"));
    for (byte i = 0; i < bytesInPacket; i++) {
      Serial.print(' ');
      Serial.print((receivedBytes[i] >> 4) & 0x0F, HEX);
      Serial.print(receivedBytes[i] & 0x0F, HEX);
    }
    Serial.println();
    newData = false;
  }
}

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

Cryptic! What raw data, and to where? I though you were using coolterm to receive data from either the Geiger counter or the Arduino. I didn't realise you were using coolterm to send data.

PaulRB:
Cryptic! What raw data, and to where? I though you were using coolterm to receive data from either the Geiger counter or the Arduino. I didn't realise you were using coolterm to send data.

i am using coolterm to receive data direct from the geiger counter to the macbook. this is the data it receives when i click the 'display HEX' button - i can display the ASCII aswell.

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

I am using Arduino IDE to send sketches to the UNO, and i am not sending anything to the geiger counter as it isnt able to receive anything.

"I haven't tested the inverse logic part of SoftwareSerial"

Well, have you checked the resting voltage on the device tx line to verify if it is RS232 or TTL logic? How have you determined the hex you have received is not just bad data due to the various ways you are receiving it?

RIN67630:
if you want to forward exactly the data received by software serial to your Mac for debugging you should have used
Serial.write() instead of Serial.print()...

great thanks, will run that sketch and see what i get and post back here (wont be for 24hours or so due to work)

david_2018:
Here is a sketch that should be able to receive and sent to serial the raw data coming from the geiger counter. I haven't tested the inverse logic part of SoftwareSerial, so not sure if that works properly, and I'm not displaying the initial 0x02 (which is an ASCII STX start of text control character).

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11, true); // RX, TX, invert signal

const unsigned long delayBetweenPackets = 1000u; //packet spacing in milliSeconds
const byte bytesInPacket = 5;
char receivedBytes[bytesInPacket];

boolean newData = false;

void setup() {
 Serial.begin(9600);
 mySerial.begin(4800);
 Serial.println("");
}

void loop() {
 recvWithStartMarker();
 showNewData();
}

void recvWithStartMarker() {
 static unsigned long lastByteReceived = 0;
 unsigned long currentByteReceived;
 static boolean recvInProgress = false;
 static byte ndx = 0;
 byte startMarker = 0x02;// ASCII STX Start of Text
 byte rb;

while (mySerial.available() > 0 && newData == false) {
   rb = mySerial.read();
   currentByteReceived = millis();
   if ((currentByteReceived - lastByteReceived) > (delayBetweenPackets / 2)) {
     //resync input if packet is not completed within allotted time
     recvInProgress = false;
     ndx = 0;
   }
   if (recvInProgress == true) {
     receivedBytes[ndx] = rb;
     ndx++;
     if (ndx == bytesInPacket) {
       recvInProgress = false;
       ndx = 0;
       byte checksum = 0;
       for (byte i = 0; i < bytesInPacket; i++) {
         checksum ^= receivedBytes[i];
       }
       if (checksum == 0) {
         newData = true;
         Serial.println(F("checksum correct"));
       } else {
         Serial.println(F("checksum error"));
       }
     }
   } else {
     if (rb == startMarker) {
       recvInProgress = true;
     }
   }
   lastByteReceived = currentByteReceived;
 }
}

void showNewData() {
 if (newData == true) {
   Serial.print(F("Packet received:"));
   for (byte i = 0; i < bytesInPacket; i++) {
     Serial.print(' ');
     Serial.print((receivedBytes[i] >> 4) & 0x0F, HEX);
     Serial.print(receivedBytes[i] & 0x0F, HEX);
   }
   Serial.println();
   newData = false;
 }
}

thank you very much, will run that sketch and see what i get, and take some screen grabs and notes and get back to you.

I would run that with the following hardware:

Macbook to UNO to TTL-RS232 converter to RS232 cable to Geiger counter

The STX is '02' (0x02 as you said) and the '14' (0x14) straight after it is the model of gieger counter (decimal 20) and the rest is calculated as per below for an example data capture of 0x02 0x14 0xAC 0x45 0xFD 0x00

I have put this into code brackets to make it easier to see, but its calculations not code, hope thats okay'

02 Start of transmission
14 Type of detector, in your case internal tube of the 6150AD
AC low byte of the mantissa, 172 in decimal
45 high byte of the mantissa, 69 in decimal
FD dose rate exponent, 253 in decimal
00 block check byte

You calculate the dose rate in this case as

mantissa = 69 x 256 + 172 = 17836

As the exponent is > 127

exponent = 253 - 256 = -3

dose_rate = mantissa * 2^(exponent - 15) = 17836 * 2^-18 = 0.068 µSv/h

thanks so much for your help, and for the sketch, i do very much appreciate it.

regards

Ed

p.s thanks to everyone for your help so far :slight_smile:

Flat4:
i am not sending anything to the geiger counter as it isnt able to receive anything.

Flat4:
on coolterm on the Mac I just have it set to send the raw data

I hope you can understand why I was confused by these statements.

PaulRB:
are you using any special feature it (the terminal program) has?

Flat4:
this is the data it receives when i click the 'display HEX' button

That's the answer I needed. I didn't get it in either posts #18 or #19.

I hope you don't think I am being unreasonably picky. I am trying to help.

PaulRB:
I hope you can understand why I was confused by these statements.

That's the answer I needed. I didn't get it in either posts #18 or #19.

I hope you don't think I am being unreasonably picky. I am trying to help.

Apologies, the error is completely mine, i meant 'receive' - sorry, sloppy fast replying on a telephone caused confusion, and of course i dont think you are being unreasonable at all - i am very grateful for your replies thus far and apologise for causing confusion!

Your help is very welcome, and appreciated

Ed

zoomkat:
"How have you determined the hex you have received is not just bad data due to the various ways you are receiving it?

Easy. On the Mac he used an RS232-USB interface, which cares for the right logic.

I also emailed the manufacturer (who was very helpful) - I sent them over a 15minute log and they decoded it for me, and verified that it was being received on the MacBook coolterm (terminal program) correctly. So I know that’s good data, I just need to get the same things out of the arduino

Ed

Looking back at the earlier post that speculated that the serial signal was inverted, that would be if you were going to feed the serial output from the geiger counter directly to the arduino, without an RS232 interface. The output of the geiger counter is semi-RS232 compatible, being the correct polarity, but only swinging from GND to VCC, never going negative. If you are going to use an RS232 interface between the arduino and the geiger counter, then the signal is the correct polarity of a normal RS232 signal.

I finally get around to hooking up a couple of arduino's and testing SoftwareSerial with inverted polarity, it does work correctly with both boards set to inverted polarity, and with both set to normal polarity, but not with one set to normal and the other set to inverted.

Great, so softwareserial does not need to be inverted if i am using an RS232 to TTL converter, but only if connecting the automess directly to the arduino.

Thanks :slight_smile:

Ed

Flat4:
great thanks, will run that sketch and see what i get and post back here (wont be for 24hours or so due to work)

thank you very much, will run that sketch and see what i get, and take some screen grabs and notes and get back to you.

I would run that with the following hardware:

Macbook to UNO to TTL-RS232 converter to RS232 cable to Geiger counter

The STX is '02' (0x02 as you said) and the '14' (0x14) straight after it is the model of gieger counter (decimal 20) and the rest is calculated as per below for an example data capture of 0x02 0x14 0xAC 0x45 0xFD 0x00

I have put this into code brackets to make it easier to see, but its calculations not code, hope thats okay'

02 Start of transmission

14 Type of detector, in your case internal tube of the 6150AD
AC low byte of the mantissa, 172 in decimal
45 high byte of the mantissa, 69 in decimal
FD dose rate exponent, 253 in decimal
00 block check byte

You calculate the dose rate in this case as

mantissa = 69 x 256 + 172 = 17836

As the exponent is > 127

exponent = 253 - 256 = -3

dose_rate = mantissa * 2^(exponent - 15) = 17836 * 2^-18 = 0.068 µSv/h




thanks so much for your help, and for the sketch, i do very much appreciate it. 


regards

Ed

p.s thanks to everyone for your help so far :)

Okay this sketch work great, but not through the TTL-RS232 converter (not sure why), but with the GND (Pin5) and Tx (Pin 2) of the Automess device connected direct to GND and Pin 10 of the Arduino i get good results in the Serial Monitor AND the CoolTerm Program i use.

I definitely needs to be inverted, it doesnt work with the 'true' set to 'false'. So thats fine.

Here is a screen grab, it shows exactly the same data in the Arduino Serial Monitor aswell, so thats excellent, and more importantly its the correct data as mathematically it calculates (me manually) using the formula in the QBASIC code sent to me by the manufacturer.


Screen Grab of serial data.

Great stuff, next step is to get that data converting using the formula, then logging onto an SD card. Then I will think about GPS....

Thanks everyone :slight_smile:

I shall probably make new threads in the relevant forum section for the next steps.

Is that the done thing, or is it preferred to keep it all in one thread?

thanks

Ed

If you are using the sketch I posted, it has a slight error - I forgot to change the data type of the receivedBytes array from char to byte. Doesn't make any difference in the sketch, but could cause some problems if you try and do math with it, since char is a signed 8-bit integer, while byte is unsigned.

"but with the GND (Pin5) and Tx (Pin 2) of the Automess device"

You on the correct pin? Pin #3 is typically the tx pin on a DB-9 male connector. Is the device serial connection male or female?

Thanks David_2018 - will change that as it will likely have an impact when I get to the stage of using the automess code to decode the data into meaningful numbers. Thanks.

Zoomkat - yes definitely, as I am receiving the correct data, which wouldn’t happen if I was on the wrong pin. The automess doesn’t receive, only transmit. The DB9 internally only has pin 5 and pin 2 connected, nothing else - so essentially I am connected to GND and Tx of the the automess

As it works connected directly to the arduino board I will eventually dump the DB9 connector and hardwire Otto the board (the other end of the cable is a Fischer/Lemo type connector)

Thanks all

Ed

david_2018:
I finally get around to hooking up a couple of arduino's and testing SoftwareSerial with inverted polarity, it does work correctly with both boards set to inverted polarity, and with both set to normal polarity, but not with one set to normal and the other set to inverted.

You did not catch that the geiger counter has a driver chip in between that inverts the signal.
So either connect both systems bypassing the driver chip or invert the polarity by software (or by hardware with a similar driver chip) if you don't want to fiddle with the geiger counter hardware.

Thanks RIN67630,

I don’t want to open the Geiger counter as it still factory sealed and calibrated, it’s all working with the arduino (serial comma wise) with the softwareserial inverted and the try-rs232 converter omitted