Won't connect

[RFburn]

I don't have much in the way of details but Windows 10 x64, the gammascout toolbox 5.36 works fine but opengammatool gets stuck at "Connecting...". No errors or any other information to point as to why, just sits there. It will get access to the COM port I assume as while connecting loading the toolbox you will get a permission denied error. Tried running as administrator, compatibility mode, other versions of Java (of 1.8 branch)

Wish there was more info I could share or logs, but I don't see anything generated. Scratch that, ran in console. Even though the com port shows correctly in the list, when selected to connect I get:

jssc.SerialPortException: Port name - COM20; Method name - openPort(); Exception type - Port not found.
        at jssc.SerialPort.openPort(SerialPort.java:167)
        at com.gammascout.usb.GammaScoutConnector.<init>(GammaScoutConnector.java:51)
        at com.gammascout.MainWindow.run(MainWindow.java:633)
        at java.lang.Thread.run(Thread.java:748)

so it just isn't opening the port correctly. Issue with newer Java 1.8.0_131 vs age of this program?

Another issue, I thought loading the CSV from the ToolBox would work but with that I get:

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 1
        at com.gammascout.fileio.TextTool.loadCSV(TextTool.java:119)
        at com.gammascout.MainWindow.actionPerformed(MainWindow.java:397)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
        at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
        at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
        at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
        at java.awt.Component.processMouseEvent(Component.java:6533)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
        at java.awt.Component.processEvent(Component.java:6298)
        at java.awt.Container.processEvent(Container.java:2236)
        at java.awt.Component.dispatchEventImpl(Component.java:4889)
        at java.awt.Container.dispatchEventImpl(Container.java:2294)
        at java.awt.Component.dispatchEvent(Component.java:4711)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
        at java.awt.Container.dispatchEventImpl(Container.java:2280)
        at java.awt.Window.dispatchEventImpl(Window.java:2746)
        at java.awt.Component.dispatchEvent(Component.java:4711)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.awt.EventQueue$3.run(EventQueue.java:703)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90)
        at java.awt.EventQueue$4.run(EventQueue.java:731)
        at java.awt.EventQueue$4.run(EventQueue.java:729)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Attached is the CSV file (added .txt to upload) Gamma-Scout 201710182351 5.36 018063.csv.txt

[erikjber]

Hi! Thank you for your bug report. Regarding the second issue, can you clarify one thing? Have you created a .csv file with gammascout toolbox 5.36, and you want to open it with OpenGammaTool?

[RFburn]

That was what I attempted to do after it wouldn't connect to the meter in OpenGammaTool. I just assumed it accepted the format, but maybe not?

[erikjber]

No, Gammascout Toolbox and OpenGammaTool uses different formats. They are superficially similar, but different.

[erikjber]

I just tested this on a computer with Windows 10, and it worked fine. Have you tried the obvious stuff (trying a different USB port, disconnecting other USB peripherals, rebooting, trying a different computer)?

[erikjber]

By the way, I've released a new version with improved zoom+pan.

[RFburn]

Tried different ports, controllers and now the new version with a new error: Exception in thread "Thread-5" java.lang.NullPointerException at com.gammascout.usb.GammaScoutConnector.getDeviceDateTime(GammaScoutConnector.java:105) at com.gammascout.MainWindow$1.run(MainWindow.java:670) at java.lang.Thread.run(Thread.java:748)

I'll try a different PC now. However, I've been using serial devices of multiple chipsets on this computer all day long with no issues. I am no longer getting the connection error, just that one above when it attempts to getDeviceDateTime (which was just synced by GammaScout ToolBox)

What version of Java are you using?

The driver being used is from FTDI version 2.12.16.0 (2016-03-09)

[RFburn]

Sadly I just broke my tube. So not much of problem anymore.

Happen to know of a replacement or the model? Getting old, might as well replace the battery too or upgrade it to rechargeable. 10 years is good though.

[erikjber]

Sorry to hear about your tube. I guess the best replacement is a new GammaScout.

The new error indicates that the device is now connected. Since I haven't changed the communication code at all, that makes it likely the connection error was on your computer all along.

The new error seems to indicate the device time was not read from the device. That, coupled with the device being 10 years old, makes me suspect it might be using the old v1 protocol. Can you find the firmware version by pressing the "Battery" button and then the "Enter" button, and let me know? Do you have a three or four digit display?

P.S. I'm using the latest Oracle java from the java.com website.

[RFburn]

Guess it isn't as simple as swapping tubes due to the calibration. I don't know how many hundreds of times I stuck a uranium doped marble near the window, but this time I accidentally let it gently fall towards the tube and I heard "pop". Not really looking to spend that much again on what was a seldom used gadget, I was just getting it all setup to do more datalogging when that happened. It is of non-critical use. Waiting to hear back if they do replacement tubes, probably an arm and a leg if they do. It is weird it displays a reading but there is absolutely no sound when the speaker is turned on and pulse count is 0.

V5.36 and display is 3 digits currently, but I can see the LCD has a 4th which isn't on/black but if I goto the date it will do 4 digits "24.10" today.

[erikjber]

V5.36 with a 3-digit display would almost certainly use protocol version 1. Version 1 is not supported, since I don't have a version 1 device to test with. Closing the bug now.

[erikjber]

Incidentally, if I decide to try to implement v1 in the future, would you be willing to test it?

[joelwutzke]

As much as I can with a broken tube. Should be able to at least test the data transfer and/or swap another tube that wont match calibration but will show if logging transfer is successful. Looks like I didn't have a LND712 which would be easy to get, it has an old centronic zp1404 (or was it 1401, I forget this second). Been damn near impossible to source a replacement and geiger scout would require replacing sensor and microcontroller as they have none of the centronic units. :(

[erikjber]

@joelwutzke Try this, it's a first attempt. It should detect the protocol version automatically.

OpenGammaTool-1.2.beta.jar.gz

[erikjber]

There's a pull request for a fix. Anyone willing to test it?

[userx14]

@joelwutzke i saw this geiger counter with a replaced tube on google images: you won't have any calibration then, but a different tube will probably just produce a different scaling factor see: http://true-random.com/homepage/projects/gmz/index.html and https://m.youtube.com/watch?v=OH5Rmd1scAU . But I would be careful, because as far as i know the tubes operate with high voltage, so disconnect the power source before anything bad can happen.

[userx14]

Made a new pull request because I failed with the number of bytes to read and therefore it also displays trash data at the moment. Here a screenshot from the updated version with and device with protocol v1:

[erikjber]

There's a new release (v1.3 beta) out now. I don't have a version 1 device, so if anyone with a version 1 device can test the new binary we can close this bug.

[userx14]

Will test it today late evening (in aprox 6h).

[userx14]

Ok I have tested release 1.3.beta: The fix for the procol detection is working as expected, it says Not connected if it the Gammascout is not in usb mode and if it is still sending the previous datastream. Everything else seems to be working, it is able to read the data from v1 protocol and I have sucessfully tried exporting an pdf.

[userx14]

Also added an function which detects the end of the procotol like you said. So I think you can close the issue, thanks for this nice tool. 👍