USB Temperature gadget driver >> ugold

Phishfry

Phishfry

Recently I stumbled onto a driver in source for the TEMPer brand of USB Temperature Sensors.
/usr/srs/sys/dev/usb/misc/ugold.c
"Driver for Microdia's HID based TEMPer Temperature sensor"

These are really common and cheap on ebay. I have four inbound tomorrow for testing along with 4 USB bases for remote use.
Anybody try these?
https://www.ebay.com/itm/263025822995
 
So upon further review the FreeBSD code is written for version 1F of the TEMPer
https://www.ebay.com/itm/302722798857

I am going to order one to check it out. I was wondering what the 'outer' field was in the code.
This unit has an external temperature probe for a secondary reading named 'outer'.

I added entries to usbdevs and ugold.c but my device is too different.
Code: 
sysctl dev.ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=2 devaddr=5 interface=0 ugen=ugen1.5
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5
dev.ugold.%parent:
The device:
Code: 
Oct 27 00:56:05 E6420 kernel: ugen1.5: <vendor 0x413d product 0x2107> at usbus1
Oct 27 00:56:05 E6420 kernel: ugold0 on uhub3
Oct 27 00:56:05 E6420 kernel: ugold0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5> on usbus1
 
Hi,

I have one of those but my system loads the ums driver instead:

Code: 
ukbd0 on uhub0
ukbd0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 2> on usbus0
kbd1 at ukbd0
ums0 on uhub0
ums0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 2> on usbus0

Does yours work?
 
Maybe that's the problem. ugold is interfering.
Code: 
 sysctl -a | grep ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=1 devaddr=3 interface=0 ugen=ugen1.3
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 3
dev.ugold.%parent:
I will try without the driver. Do you have any sysctl's?
 
No I don't know. I have found the source of my problem. The PID or Product ID is already assigned to another device in usbdevs.
So I need to try editing that again and removing the duplicate entry.
The ums driver does indeed pick up this device but that is useless for temperatures.
That ums driver is picking this up might be an artifact of the other device PID.
 
I'd rather see a userland lib to talk to the device and let the OS speak generic USB (eg. libusb20). There's no need for this in the kernel. USB is the modern equivalent of an RS232 / RS485 port - with equal complexity - meaning it isn't hard.
 
Phishfry said:
Maybe that's the problem. ugold is interfering.
Code: 
 sysctl -a | grep ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=1 devaddr=3 interface=0 ugen=ugen1.3
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 3
dev.ugold.%parent:
I will try without the driver. Do you have any sysctl's?
Click to expand...

I do, but from ums driver. Nothing useful here :(

leebrown66 said:
I don't suppose you know offhand if the TEMPer HUM (ebay) (humidity + temperature) is compatible? It's only $20 so I'll probably just end up getting one to try anyhow.

Thanks -- lee
Click to expand...

That's exactly mine. I hope there is hope :)

Phishfry said:
No I don't know. I have found the source of my problem. The PID or Product ID is already assigned to another device in usbdevs.
So I need to try editing that again and removing the duplicate entry.
The ums driver does indeed pick up this device but that is useless for temperatures.
That ums driver is picking this up might be an artifact of the other device PID.
Click to expand...

So I need to take that PID from UMS driver and recompile it? As this is a server, and the kernel is modular, if I remove ums.ko from /boot/kernel will it crash the box, or just ugold will take over as desired?

thanks.

none
 
No kldload ugold will load the module. The rest is "yet to be determined". Maybe devd.conf will be nicer.
I think a bug report is in order to get the VID/PID into FreeBSD.

I had to let this go.
Like I mentioned above in the "FreeBSD list of USB device ID's" usbdev has a PID entry already for my device.
There can not be a duplicate. It fails to compile.
So as a hack I changed the PID for the outdated hardware that I was battling(0x2107 changed to 0x2106).
That left the quirk issue out. but that don't really seem to be working right either. The sysctl is not showing any temps.

My next tact is going straight to devd and spoofing the supported PID/VID.
I got to admit it has been harder than I imagined.
There is no company named "TEMPer" and they latch onto CHICONY2 in the driver if you look at the code.
No luck.
I fooled around with the button on the device as I noticed it spews data to the terminal when you hit the button.
This only seemed to work in Xterm. A normal console I see no messages when pressing the button.
The LED is Red and I am not sure if that is right.
My device has a second external temperature probe using a mini-phono jack. I have read that it uses a onewire sensor.
 
Hi again.

All my research leads me to a bad usb device ID by the device. I tried now on Linux, using tools well tested and got nothing.

As my device won't report as temperature device even on Windows, I guess that's it. I have to buy another :(
 
Yes that does seem to be the problem.
The ProductID or PID that is assigned to most of these TEMPer's belongs to another device.
That is why Linux barfs too. Bad PID. There is a github for them to make it work.
 
Phishfry said:
Yes that does seem to be the problem.
The ProductID or PID that is assigned to most of these TEMPer's belongs to another device.
That is why Linux barfs too. Bad PID. There is a github for them to make it work.
Click to expand...

where is this github url?

All I found got me nowhere. Both FreeBSD and Linux.
 
Well, I got mine working on linux using those hints in that link above. If that was feasible on Linux, do you think it can also be on FreeBSD?
 
Yes maybe not by me but if Warner(driver author) had one he could have it going in 5 min.
I think a custom devd.conf script would do it.
This area is not my specialty.
 
Phishfry said:
So upon further review the FreeBSD code is written for version 1F of the TEMPer
https://www.ebay.com/itm/302722798857

I am going to order one to check it out. I was wondering what the 'outer' field was in the code.
This unit has an external temperature probe for a secondary reading named 'outer'.

I added entries to usbdevs and ugold.c but my device is too different.
Code: 
sysctl dev.ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=2 devaddr=5 interface=0 ugen=ugen1.5
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5
dev.ugold.%parent:
The device:
Code: 
Oct 27 00:56:05 E6420 kernel: ugen1.5: <vendor 0x413d product 0x2107> at usbus1
Oct 27 00:56:05 E6420 kernel: ugold0 on uhub3
Oct 27 00:56:05 E6420 kernel: ugold0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5> on usbus1
Click to expand...

Hi, as a small reply to this, I got this 1F version of the sensor via Amazon.de and just to know it is listed in dmesg as same vendor and product numbers :(

The same ums got loaded. No temperature numbers so far :(

Can I force ugold to load?

none
 
Phishfry said:
So upon further review the FreeBSD code is written for version 1F of the TEMPer
https://www.ebay.com/itm/302722798857

I am going to order one to check it out. I was wondering what the 'outer' field was in the code.
This unit has an external temperature probe for a secondary reading named 'outer'.

I added entries to usbdevs and ugold.c but my device is too different.
Code: 
sysctl dev.ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=2 devaddr=5 interface=0 ugen=ugen1.5
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5
dev.ugold.%parent:
The device:
Code: 
Oct 27 00:56:05 E6420 kernel: ugen1.5: <vendor 0x413d product 0x2107> at usbus1
Oct 27 00:56:05 E6420 kernel: ugold0 on uhub3
Oct 27 00:56:05 E6420 kernel: ugold0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5> on usbus1
Click to expand...

Hi,

could you share the code you wrote so it could be claimed by ugold not ums?

I tried here, no lucky. My driver coding skills are superficial.

thanks,

none
 
Long story shortened- I am not a coder either. This might best be addressed by making a Problem Report at bugzilla.
Warner Losh is a very talented programmer and is very accessible and answers emails promptly.

When I mess with the /src tree I make a separate copy so as to not contaminate my source tree.
I deleted my custom source tree after failing here.

Here is why I chose not to continue working on this.
FreeBSD uses standard 'PCI Working Group' list of VendorID and ProductID 's.
The people who make these Temper devices are using a fake ID.
This problem cascades even further in that the fake ID actually belongs to another device.
So I work with NIST calibrated standards for ensuring my manufactured parts are usable by people in Germany or Timbucktoo.
It is called standardization. The computer industry would not exist in its current form if not for standards groups.

The people making Temper are using a fake ID.
I can't help that and it causes many problems that are above my paygrade.

No offense to you I just felt I need to make myself clear. I was not ignoring you but cannot help any.

Edit: The official name is "Peripheral Component Interconnect Special Interest Group"
Membership is $4,000 a year and I feel this manufacturer probably don't want to pay their dues.
If Windows required a proper PCI-ID I bet they would pay up.
 
Back to the technical side of this.
What I did is remove the usbdevs entry for the 'other device' that TEMPer spoofs.
Then recompiled.
That errored out because the removed device entry also had hooks in another file.
So I removed references in that file as well (can't remember the name).
Then it would compile cleanly. I then added back the TEMPer device and compiled again.
Still didn't help.
 
You must log in or register to reply here.
Back
Top