USB_Dewpoint

[kris969]

I have developed an Raspberry HAT based on an Arduino nano for this driver. I will publish it as public, in the following days, just time for me to finish all necessary files for this repo. Here is the 3D view of this HAT:

It just finished all tests and it works fine with the USB_Dewpoint indi driver. I just have a suggestion concerning calibrations witch have currently limited to a range of [0 to +9]. Could it be possible to have a range of [-9 to +9]?

[knro]

@jpaana Any issues with updating calibration range as proposed above?

[jpaana]

Unfortunately the protocol to communicate with USB_Dewpoint is very limited, all commands need to be exactly 6 characters long and the command to set the calibration (SCAnnn) has only one digit per channel (1, 2, ambient) so the values really can be only 0-9. If you want negative values too, and as you have control of how your device interprets those values I suggest biasing the range with for example -4 so then 0 really means -4, 4 means 0 and 9 means 5. Unfortunately the values shown in the INDI gui would still be 0-9 though.

[kris969]

Thanks Jarno for your reply  ;)

I understand your point of view.

I am looking for the protocol communication specifications. 

The one I found is: "INDI: Instrument-Neutral Distributed Interface | Protocol Version 1.7 | Document Version 1.3 | 18 June 2007 

I'm not sure it's the good one used in our case for indi driver. Could you please confirm?  In case this document shouldn't be the good one, could you please give me a link to the correct one, I will appreciate ;)

This protocol seems to be a little tricky at first read, because it's an old school one...

If it's relevant and if I have understood (not sure of that), It could be possible to add a new command. If this case it should be possible:

• to let the (SCAnnn) command as it is, it will bring the advantage to assume backward compatibility.
• to had a new command, SCNnnn for example or whatever else, to manage negative values.

Le mardi 28 mai 2024 à 10:09 -0700, Jarno Paananen a écrit :

Unfortunately the protocol to communicate with USB_Dewpoint is very limited, all commands need to be exactly 6 characters long and the command to set the calibration (SCAnnn) has only one digit per channel (1, 2, ambient) so the values really can be only 0-9. — Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

[1] view it on GitHub https://github.com/indilib/indi/issues/2064#issuecomment-2135741296 [2] unsubscribe https://github.com/notifications/unsubscribe-auth/ACZSP4CXPMDPATVLBIXFAFDZES25VAVCNFSM6AAAAABIK4QGN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVG42DCMRZGY

[jpaana]

The protocol I'm talking about is the one used when talking to the device over serial port, not the INDI protocol. That protocol is fixed by the device firmware so we can't change it for the current USB_Dewpoint devices. There isn't a real document about the protocol as I just reverse engineered it by snooping traffic from the Windows program to the device and back, but the commands are listed in the beginning of usb_dewpoint.h in the driver. The command in question to set calibration values for example is there as #define UDP_CALIBRATION_CMD "SCA%1u%1u%1u" // channel 1-2-A, value 0-9 which is then used as format string with snprintf call to format the values to suitable format:

bool USBDewpoint::setCalibrations(unsigned int ch1, unsigned int ch2, unsigned int ambient)
{
    char cmd[UDP_CMD_LEN + 1];
    char resp[UDP_RES_LEN];

    snprintf(cmd, UDP_CMD_LEN + 1, UDP_CALIBRATION_CMD, ch1, ch2, ambient);
    return sendCommand(cmd, resp);
}

%1u means one digit of unsigned decimal input value, so if the input values are for example ch1 = 1, ch2 = 3 and ambient = 7 then the string sent to the device is SCA137. The device protocol is such that each command is exactly 6 characters and the device responds after it receives them. There is no start/stop markers of any kind which makes the protocol quite fragile to desynchronization, which is why there is a Resync function that sends up to 5 space characters to get an error message which gets the device and driver back in sync.

As your device is not actually USB_Dewpoint and you can change the firmware to do what ever you want, there's no reason to limit yourself to the USB_Dewpoint driver as such, except it being a simple way to get started. So you could make a new driver for your particular device and modify it to your heart's content :) There are also other similar devices like https://github.com/jbrazio/arduheater for which I also made a driver at one point when someone asked, but I don't think it's included in INDI as it wasn't really tested. And for example https://github.com/indilib/indi/pull/2024 is an alternative as well.

[kris969]

My objective was to develop this board for fun. It works fine with the indi usb_dewpoint driver, as you mention it was for me a simple way to get started, but not only. After using it, I consider this driver works very well. Of course I could develop my own but I prefer to stay with this one as it is validate and is part of the third party drivers. Concerning calibration, the dewnot heater doesn't need an extremely precision for temperature, the master goal is to keep temperature relative to the calculated dew point. If I can't move down the calibration of one sensor I can adjust the others to get something similar enough.

Anyway, thanks a lot Jarno for your clear response and having take time for it ;)

Le mercredi 29 mai 2024 à 03:51 -0700, Jarno Paananen a écrit :

As your device is not actually USB_Dewpoint and you can change the firmware to do what ever you want, there's no reason to limit yourself to the USB_Dewpoint driver as such, except it being a simple way to get started. So you could make a new driver for your particular device and modify it to your heart's content :) There are also other similar devices like