Do you have a TEMPer or TEMPerHum USB device? Making ASCOM driver for it. - Page 4

luka · #61 12-09-2019, 01:04 AM

That is weird. The "Get device details" button gets the data from the Device Manager. This means that your new device is not setting this and likely that the manufacturer software is reading the device info directly from the device.

Interestingly, I downloaded the PCsensor software from your screenshot and it works correctly with my TemperHum device (unlike the software that came with the device on the CD).

Anyway, the good news is that I may have found a salvation from the TemperHum hell

I have decompiled the PCsensor software and found LOTS of info there, more than enough to get a whole range of new devices working. A major change but if this works it will be a major progress!!!

Troy, does your old device work with the new software?

troypiggo (Troy) · #62 12-09-2019, 08:52 AM

G'day Luka,

Tried the old device, and it doesn't work with that PC sensor program. So perhaps the device is a dud? Or perhaps it's because of its age? Who knows.

Good news that you're able to glean lots of info from the software, though. That's awesome!

luka · #63 17-09-2019, 11:43 PM

I am looking for testers of the new driver (before releasing it into the wild).

The new version is a significant rewrite and is based on the messy code extracted from the Chinese software (instead of comments I picked up from the internet for the previous version).

The new version supports more devices than before.
Thanks to Troy

we have tested 2 devices so far.

PM me if you have a TEMPerHum device and want to try out the new driver.

luka · #64 29-09-2019, 12:40 AM

Here is a new beta version for more general public testing. Few people have successfully tested it with different devices.

Changes:
- Major code cleanup
- The driver is passing all ASCOM validations now

Two issues:
- The driver will only work with 32-bit applications (which is most of them). I have used the Chinese DLL for USB access which is 32-bit only

- Not sure how to open-source the source code any more; I had to "borrow" some calibration code from the original Chinese code

RobF (Rob) · #65 29-09-2019, 02:11 PM

Hi Luka

I'm all set up waiting for the sun to go away, so have just given this another spin with my original "temperhum 1.3" device and your latest V3 ASCOM beta, running from within Sequence Generator.

SGP crashed on first attempt, but 2nd time I unchecked the "2nd Sensor" tickbox, and seem to have success

Have dangled a 2nd thermometer nearby and the readings look believable. 40 degrees temp and 8% humidity - don't think I have to worry about fog tonight. Terrible drought once you drive inland a bit in SE Qld.

RobF (Rob) · #66 29-09-2019, 02:21 PM

Is there any way to make the driver software fail more gracefully? This is pretty nitpicky and probably outside your control, but would be good if crashes could be captured.

Same goes for Sequence Generator of course - arguably more at fault than your work I guess.

I'll try and leave the Temperhum in place all afternoon and tonight and see how it goes. Seems happy so far.

luka · #67 29-09-2019, 09:57 PM

Rob, which version did you try?

The original beta v3 did not have much error checking as the goal was to get it working first but the one with yesterday's date (v3.0 beta 20190928) should not be crashing. It should just disconnect when error occurs.

By the way, another update is coming soon, I have been doing more "polishing" (and error-proofing) and have added instructions.

RobF (Rob) · #68 29-09-2019, 10:01 PM

Have been playing on and off today with the very latest V3 Luka. Just happended to have some time today with the rig set up and noticed you'd posted a new version late last night.

It seemed ok while the rig was idling, but I've had SGP freezes a few times tonight and have taken the Temphum dongle out of the Mount Hub Pro now.
Love the work you've put into this, but my device in my system still seems very fiddly alas.

luka · #69 29-09-2019, 11:48 PM

Rob, sorry about that, hopefully you did not lose any data.

After your post I did a bit more poking around and I think that the problem is caused by the Chinese communication library (DLL) that we are using now. If for whatever reason it fails to read data from the device it just locks up the driver which then locks up SGP. My old driver had timeouts to avoid lockups but now we are relying on the DLL.
By the way, SGP is also partially to blame as it should also be using timeouts to recover and not relying that everything will always work perfectly.

While I could work around the "locking up" problem, I may spend the effort to rewrite the DLL. I can reuse the code from my old driver so it should not take too long. This was on my to do list for some later stage anyway.

troypiggo (Troy) · #70 30-09-2019, 05:41 PM

G'day Luka,

Thanks so much for sticking with this. I've been a bit flat out at work and home last few weeks, and will be for another couple. So won't get a chance to test "live" for a bit. Will let you know results when I do.

RobF (Rob) · #71 30-09-2019, 06:08 PM

Quote:

Originally Posted by luka

Rob, sorry about that, hopefully you did not lose any data.

After your post I did a bit more poking around and I think that the problem is caused by the Chinese communication library (DLL) that we are using now. If for whatever reason it fails to read data from the device it just locks up the driver which then locks up SGP. My old driver had timeouts to avoid lockups but now we are relying on the DLL.
By the way, SGP is also partially to blame as it should also be using timeouts to recover and not relying that everything will always work perfectly.

While I could work around the "locking up" problem, I may spend the effort to rewrite the DLL. I can reuse the code from my old driver so it should not take too long. This was on my to do list for some later stage anyway.

No guilt required - I was nearby all night keeping a very close eye on things, knowing well it was Beta code you'd shared. When I did pluck it in the milddle of an SGP freeze surprisingly SGP pepped up again and kept going like nothing had happened. Definitely agree that would be nice for Sequence Generator to be more robust - the programmer have frequently commented they do their best to implement ASCOM standards with expectations the gear is playing ball. Your comments re the chinese DLL seem consistent with what's been happening though.

I'm also experiencing infrequent USB challenges with my gear even without the temperhum. Wish I knew if it was power, cables, gear - trying to steadily tick off things on at a time.

Not the most reliable tester right now alas.....