My greatest respect for creating this alternative DSO150 firmware! Just tried the latest 1.0.7 release and it worked very well.
Only the USB connection gives me some trouble on my Win10 system. The port HW is connected as per your instructions. The devices registers in the device manager as serial COM port. Opening a terminal with 115200 baud seems okay, but sending "DSO0" gives no response.
indeed, If you see a "DSO" serial port it means the usb connection is ok Make absolutely sure you have no flow control (hw or sw) For information, i never tested it on windows, but i dont see why it wouldnt work
I'm getting 2 new devices (reported from USBDeview.exe): "Maple USB composite device" "0000.001d.0002.001.000.000.000.000.000 serial USB device" at COM10 The Win10 device manager only reports COM10
Weird behaviour in my system.. After a reboot the DSO's enumeration is now COM14. With TeraTerm the device replied correctly on COM14, but only once. Following pings are not answered. HTerm does not work at all. Is there any specific timing to be considered? Are any trailing characters allowed? Do you have any other example, apart from "DSO0", that gives a response?
That"s the expected behaviour The "DSO0" string is a handshake so that the scope switches to command mode The other commands are binary Please try with the python stuff, not tried on windows (it should work but not sure) A good starting point is pySerial_getInfo.py (python 3) https://github.com/mean00/DSO_STM32Duino/tree/master/pyUsb
First success :) I've built my own simple terminal (with Lazarus/Pascal), for better control of the data. The device responds with "OSD0". From a look into "dso_usbCommands.cpp" and "dso_usbCommands.h" it seems a command is 32 bit long. Therefore, to get "FIRMWARE" I send binary 4 bytes "01" + "10" + "00" + "00" and received "03" + "01" + "07". Looks right :) No luck so far with reading captured data..
Sorry for ignoring your python hint. I'm not that deep into software and had never to do with python..
Reading the captured data and the settings works fine and stable now :) Again I'm very impressed about your work. Chapeau!
Some minor findings from along the way: - the timebase has one unusual setting that doesn't match the rest: u25. Is this intentional? - USB recognition does not work when the DSO is switched on, only when re-plugging. Most likely that is a particular "feature" of my device, caused by the startup voltage behaviour of my battery/step-up supply. But perhaps a slight start-up delay in firmware (0.5s?) would be benefical?
- Would you mind to also implement to output a real screen-copy? In any raw pixel-format that also contains the colour information?
I was always fascinated by the so call "transistor testers" that identify and report pin out, features of pretty much whatever you throw at it. They are based on Atmel 328p chip, the same as arduino nano. So why not do the same thing with a STM32/Bluepill ? The STM32 is faster, has a better ADC accuracy, more memory, can do float etc... and is not more expensive. Warning : I'm doing this for fun & to learn, it might contain error & plain misunderstanding So, i watched a couple of video on the general principle on how they work. This is not a "port" but a rewrite from ~ scratch. When something is weird, i check what the original one does for comparison. Measuring resistance So first thing first : Resistance & Capacitance. These 2 will unlock the other ones. So how do we measure resistance ? What we do is a resistor divider with a know resistance value: Measure = Vcc*(RtoTest/(RtoTest+Rknown)) As far as the ADC goes, it means ADC=...
It 's not too complicated to change the board we have seen previously . You 'll need to cut some tracks, i did it with a dremel and i'm not very handy, so you'll do better. Red =Cut tracks Blue = Add wire 1- You'll need to separate the bottom connector from the ground, cut the 3 connectors BOTH SIDES. 2- Remove the small red area below the middle resistor to isolate each channels from each other Last, connect right side of each connector to the now isolated pad. Mine looks like this after the operation (ugly i know): Be wary of the small track on the left connector that leads to the left side of channel3 resistor. I cut it while isolating the right pad. Now it works, we can go back to the charger.
Continuing my "smart" battery charger, i've finally received the INA3221 module. It is the purple one you can find on ebay for ~ 5 bucks I soldered a couple of pins to be able to connect it so that i could test it and something immediately caught my attention. It is supposed to be a high side current/voltage sensor, typically in a setup like that : So you can measure the voltage supplied to the load, and the current going through it. Now, let's have a look at the module, look at the top of the following pic, where the sense connectors are. CH3/GND/CH2/GND/CH1/GND ? Wait ? What ? Yes, all the IN- pins are connected to ground, so it is a bottom current only sensor. Additionally, the - side of the shunts are ALSO connected to the ground, no only the connectors. The actual layout is like that : That raises two problems : The voltage is meaningless as we are only measuring Current x ShuntValue, not the supply volt...
My greatest respect for creating this alternative DSO150 firmware! Just tried the latest 1.0.7 release and it worked very well.
ReplyDeleteOnly the USB connection gives me some trouble on my Win10 system.
The port HW is connected as per your instructions. The devices registers in the device manager as serial COM port. Opening a terminal with 115200 baud seems okay, but sending "DSO0" gives no response.
What am I doing wrong?
indeed, If you see a "DSO" serial port it means the usb connection is ok
ReplyDeleteMake absolutely sure you have no flow control (hw or sw)
For information, i never tested it on windows, but i dont see why it wouldnt work
I just tried with teraterm on windows 10
ReplyDeleteSending DS0 i got the expected reply OSD0
Windows detects a "maple" device
it is of course DSO0
DeleteSettings are 115200, 8, 1, N, no flow control, ASCII coding, tried also CR/LF. USB is directly connected to the PC port, no hub. No success
ReplyDeleteI'm getting 2 new devices (reported from USBDeview.exe):
ReplyDelete"Maple USB composite device"
"0000.001d.0002.001.000.000.000.000.000 serial USB device" at COM10
The Win10 device manager only reports COM10
Weird behaviour in my system..
DeleteAfter a reboot the DSO's enumeration is now COM14.
With TeraTerm the device replied correctly on COM14, but only once. Following pings are not answered.
HTerm does not work at all.
Is there any specific timing to be considered? Are any trailing characters allowed?
Do you have any other example, apart from "DSO0", that gives a response?
That"s the expected behaviour
ReplyDeleteThe "DSO0" string is a handshake so that the scope switches to command mode
The other commands are binary
Please try with the python stuff, not tried on windows (it should work but not sure)
A good starting point is pySerial_getInfo.py (python 3)
https://github.com/mean00/DSO_STM32Duino/tree/master/pyUsb
First success :)
DeleteI've built my own simple terminal (with Lazarus/Pascal), for better control of the data. The device responds with "OSD0".
From a look into "dso_usbCommands.cpp" and "dso_usbCommands.h" it seems a command is 32 bit long. Therefore, to get "FIRMWARE" I send binary 4 bytes "01" + "10" + "00" + "00" and received "03" + "01" + "07". Looks right :)
No luck so far with reading captured data..
Sorry for ignoring your python hint. I'm not that deep into software and had never to do with python..
Reading the captured data and the settings works fine and stable now :) Again I'm very impressed about your work. Chapeau!
DeleteSome minor findings from along the way:
- the timebase has one unusual setting that doesn't match the rest: u25. Is this intentional?
- USB recognition does not work when the DSO is switched on, only when re-plugging. Most likely that is a particular "feature" of my device, caused by the startup voltage behaviour of my battery/step-up supply. But perhaps a slight start-up delay in firmware (0.5s?) would be benefical?
- Would you mind to also implement to output a real screen-copy? In any raw pixel-format that also contains the colour information?