T O P I C R E V I E W |
Erwin55 |
Posted - 05/17/2018 : 01:00:57 Dear All,
maybe a stupid question, does the following command <SPIR[00][00][00][10][00]>> initializes the GMC-300e+ to send 4096 Bytes, starting from memory position 0?
Has anyone in this forum some experience in downloading from GMC-counter to octave (Pkg instrument-control-0.2.3 installed and working perfect)? If yes, why do I get only 255s in the data-vector, when applying the following commands?
srl_write(s1,"<SPIR[00][00][00][10][00]>>"); data = srl_read(s1,4096);
Thanks and I appreciate any kind of small piece of advices
Alex (aka Erwin55) |
8 L A T E S T R E P L I E S (Newest First) |
EmfDev |
Posted - 05/18/2018 : 08:52:14 That's cool. No problem and I'm very glad it helped. |
Erwin55 |
Posted - 05/18/2018 : 03:53:43 I have a little problem with inserting the octave code in this forum. Hence I put it here:
h**p://www.gomatlab.de/gq-gmc-300eund-geigerzaehler-serielle-schnittstelle-auslesen-t46066.html
|
Erwin55 |
Posted - 05/18/2018 : 03:38:07 A thank you again @EmfDev. It took me one day playing arroung with the serial port only to get data nonsens and 15 minutes to solve the problem after your advice. Simply said: I changed the string to uint8, that's it.
I'll post a sample file in the next reply, if anyone is needing it, he will be lucky. |
Erwin55 |
Posted - 05/18/2018 : 01:45:38 Thanks @EmfDev. Your advice gave me the right idea how to solve my problem. For the first time I got something else as 255s. I'll now validate the results and if anything is ok I'll come back with the octave/matlab-code. Maybe it helps another user. |
EmfDev |
Posted - 05/17/2018 : 10:18:27 @Erwin, those CFG_SPI_DataReadAddress0..etc are no longer used so you don't need to worry about them.
For the SPIR, make sure the auto save on the device is ON every second mode to check if working.
And your command looks incorrect. srl_write(s1,"<SPIR[00][00][00][10][00]>>");
The command should be "<SPIR" ==>> these are corrent in ascii but you can't write 0x00 in ascii cos it's NULL.
so one way is to send the full command as hex for example:
3c 53 50 49 52 00 00 00 10 00 3e 3e =>> these correspond to < S P I R [00] [00] [00] [10] [00] > >
|
Erwin55 |
Posted - 05/17/2018 : 07:05:24 Hello ullix, and thanks for your quick response. Octave is a matlab-clone hosted at sourceforge. To be honest, the parsing is not the problem I have. All commands are working fine in both directions. Only SPIR command is not working as I'm expecting. The transfer ist ok but I'm receiving only FFs. Independent from starting address and data size (<= 4096). Currently I'm not looking for another program and to use the csv from the Data Viewer is my work arround, but to have a direct memory access to the measured data would be more efficient. I'll take my time to look in your manual and also in the scripts supplied and cheers for any hint.
|
ullix |
Posted - 05/17/2018 : 05:31:18 Welcome to the GQ World of firmware bugs!
And you do realize: after the download some heavy parsing is required?
It is all incorporate in GeigerLog, which is Open Source and available here: https://sourceforge.net/projects/geigerlog/ The manual to GeigerLog has an in-depth discussion of all the bugs and intricacies relevant for your counter. Reserve some time !
I am not quite sure what octave is. At the end you might be better off by downloading via GeigerLog and continue using the GeigerLog-produced History and Log files.
|
Erwin55 |
Posted - 05/17/2018 : 05:07:59 I performed a configuration dump. The result is disturbing me: 11111111-> 38 CFG_SPI_DataSaveAddress2 11111111-> 39 CFG_SPI_DataSaveAddress1 11111111-> 40 CFG_SPI_DataSaveAddress0 11111111-> 41 CFG_SPI_DataReadAddress2 11111111-> 42 CFG_SPI_DataReadAddress1 11111111-> 43 CFG_SPI_DataReadAddress0
Can someone explaint it to me? |