GQ Electronics Technical Support Forum Active Users: / Visits Today:
Highest Active Users:
GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 2.GQ Geiger Muller Counter
 Software Trouble with GMC-800

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List Spell Checker
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

   Insert an Image File
Check here to include your profile signature.
    

T O P I C    R E V I E W
ullix Posted - 02/02/2024 : 05:44:43
A user has provided me with details on the GMC-800 for proper integration into GeigerLog. If you want to follow see pre-releases pre67 and later on the "GeigerLog Development Versions" site:
https://sourceforge.net/p/geigerlog/discussion/devel/

The GMC-800 manual still encourages "Third party software developers", but unfortunately points to a document of over 10 years ago, which is no longer valid for the 800 :-(

@EmfDev: could you post an update to that document GQ-RFC1201 ? If not, could you at least post the new memory configuration and explain which commands are no longer supported, or have changed in what way?

16   L A T E S T    R E P L I E S    (Newest First)
EmfDev Posted - 03/11/2024 : 11:24:41
The GMC-800 should be using a different protocol than RFC1201 because of the CPM difference.
wikilicious Posted - 03/07/2024 : 19:37:06
quote:
Originally posted by EmfDev

Hi wikilicious, the GMC-800 uses 4 bytes as 2 bytes are not enough for higher readings as it can only go up to 65535.
The original RFC1201 was made for the old GMC-300 and 320 models. But now all of them are updated and are using 4 bytes. I will forward this to support for them to update the user guide.



@EmfDev
Can you clarify? Are you saying Models 'GMC-300', 'GMC-320', etc. which are documented to follow RFC1201 may be updated to not follow RFC1201?
Or... specifically, just GMC-800?
ullix Posted - 03/06/2024 : 03:45:10
@wikilicious : now I see what you mean. QA is optional ;-)
EmfDev Posted - 03/05/2024 : 17:26:01
Hi wikilicious, the GMC-800 uses 4 bytes as 2 bytes are not enough for higher readings as it can only go up to 65535.
The original RFC1201 was made for the old GMC-300 and 320 models. But now all of them are updated and are using 4 bytes. I will forward this to support for them to update the user guide.
wikilicious Posted - 03/05/2024 : 16:57:56
quote:
Originally posted by ullix

The 4 byte responses were first used in 2018, see e.g. my "simple versions" of GeigerLog.
https://sourceforge.net/projects/geigerlog/files/



Sure, RFC1801 was added in 2018 which uses 4 bytes for cpm.

The comment was for GMC800
RFC1201 (https://www.gqelectronicsllc.com/GMC-800UserGuide.pdf)
Which specifies <GETCPM>> as 2 bytes (TWO BYTES)
ullix Posted - 02/29/2024 : 01:03:56
The 4 byte responses were first used in 2018, see e.g. my "simple versions" of GeigerLog.
https://sourceforge.net/projects/geigerlog/files/
wikilicious Posted - 02/28/2024 : 13:05:49
I ended up ordering a GMC-800 to figure it out myself....
Guess what I found?...
GETCPM is not 2 bytes as listed in RFC1201... it's 4 bytes.


b'<GETVER>>'
b'GMC-800Re1.08'

b'<GETCPM>>'
b'\x00\x00\x00\x0c'

b'<DSID>>'
b'\xac\x994569\x03\x06'


EmfDev Posted - 02/06/2024 : 10:33:38
Yes, the device will read out the reading in CPM, µSv/h, mR/h, or in CPS. The voice data is stored on a dedicated voice chip. There is a function on the eeprom to erase the whole chip but surprisingly, it was not added to the commands.
ullix Posted - 02/06/2024 : 00:46:52
quote:
SETVOICEVOLUME - replaces speaker volume 0-15. holding the back button will readout the radiation reading.
Does it mean the counter is talking to me? Looks like some programmer had a fun day ;-)))

quote:
SPIPW - eeprom page write SPIPW[adr1][adr2][adr3][number of bytes highbyte][number of bytes lowbyte] then followed by data
Does this allow for a faster erasure of the whole memory by writing to address 0, 0, 0 all 2 MB of 0xFF? Presently erasure had only be possible by erasing sector after sector, which is rather slow, and you have just doubled the memory.

What I would welcome is a command to the counter like "Are you talking xyz?" with a response yes or no. Feel free to add some icing, like command format (see the SPIPW statement) and lenght and format of the response. This could replace your RFC documents; which were last updated 6 years ago! ROM-size should not be an issue, when you can store speech info!

Speaking of response: what is the length and format of the DSID response?
EmfDev Posted - 02/05/2024 : 14:11:31
[quote][i]Originally posted by ullix[/i]
[br]Thank you!

I see quite a few commands, which did not exist before GMC-800, and so are not described in your GQ-RFC* documents. Are they documented elsewhere? Can you provide this doc?

I am missing on those Commands:
DSID
SETVOICEVOLUME
SPI_ID
SPIPW
SPISE
SetSPISA
GetSPISA

Is the endianness "Little" or "Big"?

Dumping the "save threshold" opton is surely a good change!

Can the tube voltage still be read-out? From what I saw I believe you can only set numbers on an arbitrary scale (like: Level:47) but still need an High-Ohm DVM to actually measure it?

I am realizing now that this counter has no WiFi? Too bad.

[/quote]

The SPI commands are for the memory storage. Some are not useful.

DSID - 2nd part of serial number sometimes needed when upgrading firmware
SETVOICEVOLUME - replaces speaker volume 0-15. holding the back button will readout the radiation reading.
SPI_ID - returns the spi eeprom chip id. Not really useful for users
SPIPW - eeprom page write SPIPW[adr1][adr2][adr3][number of bytes highbyte][number of bytes lowbyte] then followed by data
SPISE - erases sector of the spi chip.
SetSPISA - sets memory save address
GetSPISA - gets current memory save address
wikilicious Posted - 02/05/2024 : 11:53:12
I too used RFC1201 as the spec for GMC-800 in https://github.com/Wikilicious/pygmc

@EmfDev can you answer @ullix's questions in Reply#3?
geomarcos Posted - 02/04/2024 : 08:07:17
In the user manual for the GMC500+, the instrument background is <3 pulses/s (up to 180 CPM), so the GMC800 is "more precise".

I suppose that is an errata and it refers to < 3pulses/minute.
ullix Posted - 02/03/2024 : 05:19:03
This looks like a really major problem. From the GMC-800 manual, page 5 (I leave the big size, so you can really see what the manual says!):



The background of the counter, even without any external radiation, is somewhere between 0 (zero) and 2 CPS? This is zero to 120 CPM?

So the counter creates a background, which could be over 6 times what older counters have as background, namely around CPM=20.

Really?
ullix Posted - 02/02/2024 : 22:36:34
Thank you!

I see quite a few commands, which did not exist before GMC-800, and so are not described in your GQ-RFC* documents. Are they documented elsewhere? Can you provide this doc?

I am missing on those Commands:
DSID
SETVOICEVOLUME
SPI_ID
SPIPW
SPISE
SetSPISA
GetSPISA

Is the endianness "Little" or "Big"?

Dumping the "save threshold" opton is surely a good change!

Can the tube voltage still be read-out? From what I saw I believe you can only set numbers on an arbitrary scale (like: Level:47) but still need an High-Ohm DVM to actually measure it?

I am realizing now that this counter has no WiFi? Too bad.
EmfDev Posted - 02/02/2024 : 10:39:34
Most of these are not used like the old calibration and alarm. And the save threshold also are not used anymore. And disregard the numbering.

POWERONOFF,
AlarmOnOff,
SpeakerOnOff,
GRAPHIC_UNIT,
BackLightTimeoutSeconds,
IdleTitleDisplayMode,
AlarmCPMValueHiByte, //6
AlarmCPMValueLoByte,
CalibrationCPMHiByte_0,
CalibrationCPMLoByte_0,
CalibrationuSvUcByte3_0,
CalibrationuSvUcByte2_0, //11
CalibrationuSvUcByte1_0,
CalibrationuSvUcByte0_0,
CalibrationCPMHiByte_1,
CalibrationCPMLoByte_1, //15
CalibrationuSvUcByte3_1,
CalibrationuSvUcByte2_1,
CalibrationuSvUcByte1_1,
CalibrationuSvUcByte0_1,
CalibrationCPMHiByte_2, //20
CalibrationCPMLoByte_2,
CalibrationuSvUcByte3_2,
CalibrationuSvUcByte2_2,
CalibrationuSvUcByte1_2,
CalibrationuSvUcByte0_2, //25
IdleDisplayMode,
AlarmValueuSvByte3,
AlarmValueuSvByte2,
AlarmValueuSvByte1,
AlarmValueuSvByte0, //30
AlarmType,
SaveDataType,
SwivelDisplay,
ZoomByte3,
ZoomByte2, //35
ZoomByte1,
ZoomByte0,
SPI_DataSaveAddress2,
SPI_DataSaveAddress1,
SPI_DataSaveAddress0, //40
SPI_DataReadAddress2,
SPI_DataReadAddress1,
SPI_DataReadAddress0,
nPowerSavingMode,
nSensitivityMode, //45
nCOUNTER_DELAY_HiByte,
nCOUNTER_DELAY_LoByte,
nDisplayContrast,
MAX_CPM_HIBYTE,
MAX_CPM_LOBYTE, //50
nSensitivityAutoModeThreshold,
LARGE_FONT_UNIT,
nLCDBackLightLevel,
nReverseDisplayMode,
nMotionDetect, //55
bBatteryType,
nBaudRate,
nCPMSpeakerOnOffCalib,
GRAPHIC_MODE,
nLEDOnOff,
nHCPMCAL,
nSaveThresholdValueuSv_m_nCPM_HIBYTE,
nSaveThresholdValueuSv_m_nCPM_LOBYTE,
nSaveThresholdMode,
nSaveThresholdValue3,
nSaveThresholdValue2,
nSaveThresholdValue1,
nSaveThresholdValue0,
FAST_ESTIMATE_TIME,
RTC_OFFSET,
ALARM_VOLUME,
TUBE_VOLTAGE,

CALIBRATION_CPM_MSB_0,
CALIBRATION_CPM_LSB_5 = CALIBRATION_CPM_MSB_0 + 23,
CALIBRATION_USV0_BYTE3,
CALIBRATION_USV5_BYTE0 = CALIBRATION_USV0_BYTE3 + 23,

CLICK_SOUND,
SPEAKER_VOLUME,
VIBRATION,
DOSIMETER_UNIT,

ALARM_CPM_BYTE3,
ALARM_CPM_BYTE2,
ALARM_CPM_BYTE1,
ALARM_CPM_BYTE0,

THEME,
DARK_THEME_COLOR_BYTE1,
DARK_THEME_COLOR_BYTE0,

EmfDev Posted - 02/02/2024 : 10:34:57
Commands:
GETVER
GETSERIAL
DSID
FACTORYRESET
KEY
REBOOT
POWEROFF
POWERON
SETDATETIME
GETDATETIME
GETCPM
GETCPS
HEARTBEAT
SETVOICEVOLUME
GETCFG
ECFG
WCFG
CFGUPDATE
SPI_ID
SPIR
SPIPW
SPISE
SetSPISA
GetSPISA

GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.05 sec. Snitz's Forums 2000