Does anyone have the source code for the gmc300 app for this project to use the GMC-300 series hardware?

This is a bug on the newer versions of the hardware the overflows the initial version check causing bad readings for the first and sometimes second reading.

I tried to contact TJM who made the app, but I've got no response from him. Others have tried contacting the administrator here (and at Universe@home) with no luck.

So I'm making a thread seeing if we can get a solution to this.

absolutely. hopefully someone can upload the linux code for GMC300.

currenly using the windows code works with wine on Linux, and the results from a GMC-300S are not so bad, but will be better if we can get the code to make the necessary modifications.

I think you'll see many more users from the US and around the world if the GMC300 units can be used without issues (the current GMC-300E+V4 units provide bad results due to a combination of device firmware anomalies, the mfg unwilling to fix firmware, and bad coding in the application). if we can get the source code, we can both fix the application issues, but also provide apps for linux and raspberri pi. a detector like this with no real computation being done is perfect for a low power device like a Pi.

i think removing the <GETVER>> command will probably solve all the problems.

I'm watching this with interest. But I'll want to wait to see if a Linux app can be made to work, and it's clear which specific unit gives the least trouble.

right now I think the GMC-300S causes the least trouble, unless you can get your hands on a much older GMC-300 model (not "E") which should work without any issues.

but if we can ever get our hands on the proper source code for this device, then I think pretty much all of them could be made to work without issues.

I'm gonna order a 300S here soon and give it a run. It's a more accurate, but still not correct.

And a raspberry pi app would be awesome for these things for sure.

I'm going to try reaching out to TJM again, but it's not looking promising.

I find it surprising that I haven't yet got the attenion of Krzysztof either here or at Universe, via PM or email.

Hope he is just super busy and not something else.

Hoping he is just super busy.

We really need some administrative help with getting these GMC-300x sensors working correctly.

As mentioned at TeAm AnandTech's forum, I am looking into rewriting the gmc300 application from scratch (based on the available radac_1.77 source code). I am going by the assumption that TJM's gmc300 code is lost forever.

A Linux version should be my first goal, a Windows port after that, and later a multiplatform app with transparent support for both R@h's own hardware and GQ devices in a single application, for potential integration into Radiactive@Home proper.

Caveat: I never have much spare time, hence progress will be arbitrarily slow. At minimum, glacially slow.

But there is a basic problem with adding support for more devices to Radioactive@Home: As TJM already pointed out, different Geiger-Müller counters have different CPM to µSv/h conversion factors. For the time being, this conversion happens on Radioactive@Home's server, with the conversion factor for Radioactive@Home's native hardware baked in. Possible approaches:

– Best would be to extend the client-server protocol to communicate the proper conversion factor from client to server. We might very well need different conversion factors for some of the GQ devices which we could support; I haven't checked yet.
– Or the client could send adjusted pulse counts to the server. This assumes that all what the project is interested in is the µSv/h timelines, not the real pulse count records.
– Or we could live with the error. After all, I suspect that the currently supported hardware is not energy calibrated anyway, and several of the GQ devices cannot be user-calibrated (and those which can be, more likely won't ever be).