|
Post by donnybowers on Mar 12, 2019 7:55:20 GMT -5
I have this cheap little USB voltage data logger that I use to collect data on some experimental batteries I've made. The software that came with it is atrocious. I would love to learn how to hack into it and figure out how to make it interact with a program of my own making.
Anyone have any code that they've used to hack into something like that to figure out it's data patterns? It's just a single channel voltage data logger. All it does is create a file that has begin date and time on the first line. Every line after that is just a single voltage reading, then an end date and time on the last line. You'd think it would be easy to figure out how to converse with it, but I have absolutely no experience with this kind of programming. I did try playing around with it once using some code I found on one of the old LB sites, but I just couldn't get nowhere. Not even the first date and time line.
You can save the data in two different formats with the junky software that came with it. One is plain ASCII and the other is either some kind of random access file or else a database. Databases is another area I've messed with very little, but I would just save my data in ASCII files anyway. I just like that kind of file for a lot of different reasons, unless there's a good reason to use a database, like security of sensitive data. This voltage data is in no way sensitive data.
I know I wouldn't have any trouble making a better graphical interface for the data charting, but I'm lost on figuring out how to read and write to it and get the pattern of the data flow. If I could get it hacked and figure out how to communicate back and forth with it, I could easily handle the rest of the programming to display and store the data using LB.
From the looks of it, it probably has a board similar to an Arduino in it and a simple way to sense the voltage. I'm thinking it might just have a voltage divider in it that is used to get the voltage, because the resolution of the data is very low. And that's really all I need for my usage. I've even thought about getting an Arduino and setting up a voltage divider type sensor to it and making my own, but again, I have very little experience in this kind of thing.
|
|
|
Post by Rod on Mar 12, 2019 8:11:13 GMT -5
Is there a brand name or support site to browse?
Plug it in and run this code.
' list available COM ports and display info
for PortNumber = 1 to 15 lpFileName$ = "COM"; PortNumber
dwCreationDistribution = _OPEN_EXISTING hTemplateFile = _NULL
calldll #kernel32, "CreateFileA", _ lpFileName$ as ptr, _ dwDesiredAccess as ulong, _ dwShareMode as ulong, _ lpSecurityAttributes as ulong, _ dwCreationDistribution as ulong, _ dwFlagsAndAttributes as ulong, _ hTemplateFile as ulong, _ hFileHandle as ulong
print lpFileName$,
if hFileHandle = _INVALID_HANDLE_VALUE then call DisplayError else print "Available and Unused";hFileHandle
calldll #kernel32, "CloseHandle", _ hFileHandle as ulong, _ result as boolean end if next
' avoid closing the window when run as TKN print input "Hit ENTER to exit ..."; dummy end
sub DisplayError calldll #kernel32, "GetLastError", _ ErrorCode as ulong
dwFlags = _FORMAT_MESSAGE_FROM_SYSTEM nSize = 1024 lpBuffer$ = space$(nSize); chr$(0) dwMessageID = ErrorCode
calldll #kernel32, "FormatMessageA", _ dwFlags as ulong, _ lpSource as ulong, _ dwMessageID as ulong, _ dwLanguageID as ulong, _ lpBuffer$ as ptr, _ nSize as ulong, _ Arguments as ulong, _ result as ulong
print "Error "; ErrorCode; ": "; left$(lpBuffer$, result) end sub
|
|
|
Post by donnybowers on Mar 12, 2019 8:20:56 GMT -5
Oh. The website is crap. No real support that I can find. In fact, I've lost the software disk and I can't even download the software from it. It's a really cheap unit. I think I paid about $30 for it new. The brand name is Accuzact DAQ The one I've got is an 8 bit single channel something like the one on this web page at their website only I think it's -0 to +30v. It's an older model from several years ago: Accuzact -0 to +25v Voltage Data Logger
Thing is, it's a neat little unit for what i use it for. Someday I may break down and get a better one, but I don't really need anything fancy for the information I'm trying to collect.
|
|
|
Post by donnybowers on Mar 12, 2019 8:40:04 GMT -5
Wow! Too many com ports. I only actually have 3 ports on the laptop. One has a keyboard/mouse dongle. One has a cheap speaker system plugged in and the other has the data logger.
|
|
|
Post by donnybowers on Mar 12, 2019 8:54:19 GMT -5
So I hooked up an old 3.7v phone battery to the unit and the results changed. Before com 1 & 2 were both error 5, and com 3 was error 0. Now 1 & 3 are error 5 and 2 is error 0.
|
|
|
Post by Rod on Mar 12, 2019 8:58:55 GMT -5
They wont be com1 ,com2 ,com3. They might be but they are more likely to be virtual com ports which can be numbered com11 com12 etc. But if you know it is appearing as a com port (unplug/plug) then its pretty certain its just sending a stream of data as asc characters. These things usually have a two way conversation with the PC sending setup commands and receiving the response. Not having the manual is a problem. The correct way to hack it is to use something like PortMonitor to look at what is passing over the serial port. That way you can see what message the pc sends to start the data acquisition. It might be easier than that because it might be possible to set it up using the original software to send a stream of data on power up. You should browse the setup options on the original software. With the PC software closed, simply try plugging it in and read the serial port with Liberty. If it is sending a stream of readings you will be able to work out the data format. I will put some code together to read the port. In the meantime you could browse this if you have not already. alycesrestaurant.com/lbpe/AccessingSerialPort.html
|
|
|
Post by donnybowers on Mar 12, 2019 9:00:13 GMT -5
Okay. So then I unplugged the data logger and still got the same results I did the second time after I hooked up the battery to the leads. Hmmm.
|
|
|
Post by Rod on Mar 12, 2019 9:18:10 GMT -5
On my machine with a usb based GPS dongle I get this.
COM1 Error 0: The operation completed successfully. COM2 Error 0: The operation completed successfully. COM3 Error 0: The operation completed successfully. COM4 Available and Unused1184 COM5 Error 0: The operation completed successfully. COM6 Error 0: The operation completed successfully. COM7 Error 0: The operation completed successfully. COM8 Error 0: The operation completed successfully. COM9 Error 0: The operation completed successfully. COM10 Error 0: The operation completed successfully. COM11 Error 0: The operation completed successfully. COM12 Error 0: The operation completed successfully. COM13 Error 0: The operation completed successfully. COM14 Error 0: The operation completed successfully. COM15 Error 0: The operation completed successfully.
So clearly it was connected as a serial link on com4. This code read the data stream.
'change com port to the one you think the DAQ is connected to open "Com4:9600,n,8,1,ds0,cs0,rs" for random as #com
timer 100, [readport] wait
[readport] timer 0 i$=input$(#com,lof(#com))
if i$="" then count=count+1 else for n= 1 to len(i$) print asc(mid$(i$,n,1)) next i$="" end if if count>500 then [quit] timer 100, [readport] wait
[quit] close #com end
Alas it may not be connecting as a serial link. Does anything change if the software is up and running and the DAQ connected?
|
|
|
Post by donnybowers on Mar 12, 2019 9:47:44 GMT -5
I think I'm going to have to get the Windows computer from the garage and figure out a place to set it up. Right now I'm running this through Wine on Linux, and I think that might be a problem. Not sure, but those readings I was getting seem a bit weird. For all I know the device may not even be compatible with Linux. I would think that Wine would let me read USB ports, But I know the DAQ software wasn't compatible with Wine. That's why I set up a Windows machine for it in the first place. But that machine is unhooked and in a pile in the garage right now.
I'll try to get it set up somewhere by tomorrow and then I can see if the results I get are different. The second code you gave me kept saying "file already open". Probably because I'm using Wine, and I've been having problems with Liberty Basic in Wine every since I put a new Linux system on here a couple months ago. I've been using a virtual machine with XP for all my LB4 programming lately, but that wouldn't work for this because it won't interface with my USB devices.
It might take a day or two to figure out where I'm going to put that computer.
I appreciate your help with this Rod. I'm really interested in this project, so I'll probably be posting more here soon. I will find a place to hook up that Windows 7 computer and I'll try this code on that. I'll also try it with the DAQ software up and running. I have some batteries I've been thinking about doing some tracking on anyway, so I'll probably try to find a semi-permanent place for that computer.
|
|
|
Post by Chris Iverson on Mar 12, 2019 15:55:30 GMT -5
If it's a USB device that pretends to be a serial port, Linux actually generally has pretty good support for those. I don't know how well that support would pass through the WINE layer, but Linux is usually smart enough to map USB serial devices to virtual serial devices in the system, much like how Windows does.
Serial-to-USB chipsets are very common, and most are supported pretty decently on Linux, due to being fairly simple. Heck, (psuedo-)FTDI ones are often better on Linux, due to FTDI being jerks in response to other jerks, and doing stupid things with their Windows drivers in response. The Linux FTDI drivers aren't written by FTDI, so they just work, without the nonsense.
For those interested, FTDI makes a VERY prolific USB-to-Serial chipset, and may have been one of the first. Due to this, tons of quasi-legal clones were made of FTDI chips. (Made in places like China, where the legality of such copying is anywhere from up-in-the-air to just legal due to not bothering). FTDI weren't happy with the fact that clones existed, so they rewrote their drivers to either crash/BSoD the system or fill the serial buffer up with junk data when it detects counterfeit clones, preventing operation of serial devices, and possibly breaking them.
Now, it's understandable that FTDI would be upset about the clones, and this kind of thing is within their right to do(it's their driver, after all). However, it doesn't punish the companies making the actual clones; and it doesn't even punish the customers of companies who make clones. it punishes the end users who have devices that may have counterfeit chips in them that they have no idea about. (Heck, sometimes the manufacturers of the end-users' devices don't know; if part of their supply chain gets unknowingly swapped out for fakes, sucks to be them.) FTDI's response to end-users being upset about devices randomly crashing or breaking their stuff, and manufacturers who intend to by genuine, but end up receiving fakes? "Meh." A shrug, and a "don't buy counterfeit stuff."
Again, this all works fine on Linux, because their wrote their own drivers for FTDI devices that doesn't care what's actually listening at the other end.
This is why many people have started to avoid FTDI stuff, and started working with things like the CP210x chipset. Same functionality, no risk of getting a bad batch and getting hit with BSoDs and bricks.
(Only reason I know this is because I ran into this exact issue with a USB-to-TTL-Serial cable I bought for my Arduino, CHIP, and Raspberry Pi. Thing works great when plugged into a Linux computer. BSoD's within ten minutes on Windows. Got a CP210x as a replacement.)
|
|
|
Post by donnybowers on Mar 13, 2019 3:10:00 GMT -5
So I tried both pieces of code with LB5 alpha. The first code to check all of the ports didn't work yesterday, which is why I went to LB4 after that. But, I just now tried the 2nd code to read the data stream on 15 com numbers, one by one and every one gave a read limit error. I didn't want to submit this as a potential LB5 bug because I don't really know what I'm dealing with yet. When I get my Windows machine set up I'm guessing I might have a better idea of whether this device is still working and if I can communicate with it or at least get a reading that it's there. I've been doing some reading at Alyce's website about serial ports. Hopefully if I go over that material I'll at least get a better understanding of the vocabulary. It's definitely a learning curve for me, but I'm thinking I may get myself an Arduino one of these days. I need to learn a little about this stuff before I do because I would like to mainly control my projects with Liberty Basic.
What I would actually like to do is have an Arduino with an SD card and a voltage sensor, perhaps using a simple voltage divider. The Arduino would then append a voltage reading about every 20 or 30 minutes to a file on the SD card. Maybe use a comma delimited file that would also record date and time (not really necessary, but would be a nice feature). The idea is hopefully to be able to actually run the Arduino from the battery that I'm testing using a buck converter. I would like it to not be dependent on always being connected to a computer.
Then I would make a program (separately on my PC) that would store and chart the data in a way that helps show the potential of these batteries over time using the data harvested from the Arduino project. The accuracy of the device would really only have to be within about a half a volt because the main info I'm after has more to do with how well various sizes of solar panels can keep it charged under various current loads, and also to see any degradation in a battery's capacity over time under a consistent load. I could even build an adjustment into my charting program to make up for any offset in actual voltage vs the readings I'm getting if necessary.
|
|
|
Post by Rod on Mar 13, 2019 4:02:10 GMT -5
Both sets of code failed for me, LB5 has no API capability yet so the find port code I expected to fail. The readmessage code failed to open the com port with an "illegal volume" error. It's too early to expect LB5 to handle this. I would say that your DAQ may not be using serial protocol to talk to the PC. It may be a dedicated USB link which would be a lot harder to read and write. We have played with the Arduino before. There is some code on the LBPE. Firstly a Sketch that ties the Arduino to Liberty. It basically listens for Liberty sending it things to do. When it gets a message it acts on it and returns the reading or confirmation. It works well but it makes the Arduino a slave of the PC so will not suit your project plan. I would highly recommend getting an experimenters kit from Arduino and having a play. You will need to learn how to write a Sketch but there is a fantastic help community. Everything you are thinking about will have been coded and shared. alycesrestaurant.com/lbpe/Fun%20with%20the%20Arduino.htmlThere are a couple of projects to read up on.
|
|
|
Post by Accuzact on Nov 10, 2019 16:26:19 GMT -5
Hi donnybowers:
Any update?
|
|