This Noobs 1.4.1 doesn't boot on my PI3. If you observe, the newer releases (I've checked the 2.1) have files like bcm27*, which seem to correspond to the different hardware versions. The 1.4 has no such files.
USB tested OK, so both USB and LAN are fully functional on the Rigol DM3068. I have the Rigol DM3068 scripts working. Is there a GITHub I can do a pull request to get the DM3068 added. Then other people can enjoy.
USB tested OK, so both USB and LAN are fully functional on the Rigol DM3068. I have the Rigol DM3068 scripts working. Is there a GITHub I can do a pull request to get the DM3068 added. Then other people can enjoy.plesa created this repository:
https://github.com/PlesaEEVBlog/RPi_LogNut
@plesa please accept my pull request for the initial content, so that it doesn't get out of sync for too long.
I have not tried the http.server and I would like to see how easy it is to implement.
I just tried the webserver, now I can read the value of my benchtop multimeter which has only RS232, in a webpage and even from the internet, if I would add a NAT rule to my router
https://github.com/FrankBuss/RPi_LogNut/blob/master/pub/python/HM8012_Webserver.py
How it looks like (the real version reloads automatically every second) :
Of course, this is just a quick hack. You would not create the web pages in the Python code, but state of the art is probably to use some WebSocket API, serve local static files and then some JavaScript communicates over the WebSocket with JSON requests with the Python script.
Nice
plesa
How do you create images? Just simple plain bit-bit clone of SDcard, or there is some tool?
I'd like to make few images too, for DE1-SoC FPGA board running linux-gpib. Got I2C working today with BME280 on it. Next step is GPIO and SPI, so I can control ADCs/DACs as well.
USB tested OK, so both USB and LAN are fully functional on the Rigol DM3068. I have the Rigol DM3068 scripts working. Is there a GITHub I can do a pull request to get the DM3068 added. Then other people can enjoy.plesa created this repository:
https://github.com/PlesaEEVBlog/RPi_LogNut
@plesa please accept my pull request for the initial content, so that it doesn't get out of sync for too long.
#raspberry pi 2/3
KERNEL=kernel7
export KERNEL=kernel7
@FrankBuss
SPD3303 is very slow at handling commands.
You need to put a sleep after the command or it get messed.
I use something like this:
siglent.write("INST CH2")
time.sleep(1)
siglent.write("CH2:VOLT 0")
time.sleep(1)
siglent.write("CH2:CURR 1.3")
time.sleep(1)
siglent.write("OUTP CH2, ON")
time.sleep(1)
you can also lower sleep to 0.1 seconds if you need more speedy setup.
print(siglent.ask("*IDN?"))
Additional benefit of using the USBTMC kernel driver: you can use it from other programs as well, not just from Python. On my PC I can do this:
echo "*IDN?" > /dev/usbtmc0
cat /dev/usbtmc0
and it answers with
Siglent Technologies,SPD3303,SPD00002130137,1.01.01.01.05,V1.1
(but still with the timeout problem: after printing this line it hangs for about 5 seconds and then it says "cat: /dev/usbtmc0: Connection timed out")
The timeout "problem" isn't a problem at all but just how the usbtmc protocol is implemented.
The cat program keeps on reading till it receives an EOF.
Usbtmc protocol uses a newline character at the end of a message, not an EOF.
Cat ignores the newline character and will continue to ask for more data till the driver timesout which is after 5 seconds.
A program that is written to read from an usbtmc device will stop reading when it detects a newline character in the message.
1.) A *logging* platform should definitely log to a real hard drive because the process of logging inherently makes a great many individual writes which will destroy flash memory cards eventually. (For the same reason compiling software on them will, hopefully people know that)
Good practice would be to put the boot OS on the SD card and do all logging - also any compiles, should take place on a real HD which can be a small one. SD cards have improved a lot but this is still good practice. You should also use the real HD for swap.
1.) A *logging* platform should definitely log to a real hard drive because the process of logging inherently makes a great many individual writes which will destroy flash memory cards eventually. (For the same reason compiling software on them will, hopefully people know that)
Good practice would be to put the boot OS on the SD card and do all logging - also any compiles, should take place on a real HD which can be a small one. SD cards have improved a lot but this is still good practice. You should also use the real HD for swap.
Another idea is to use a network drive. I have a NAS (with RAID0) and copied the /pub directory to it. Then I mounted this directory from my Raspberry Pi, now doing some long time logs for the Batteroo test. But probably not a good idea to use swap over ethernet. Best would be to disable swap and mount the main filesystem read-only, using the rest from the NAS.
Some time ago for another platform I could even load the Linux kernel over network with u-boot, and then even mount the root filesystem over NFS. This is really helpful for developing, because then you don't have any size limitations of the platform and testing new kernel versions is faster, and it can't brick, if you backup the last kernel (and modules).
@FrankBuss
SPD3303 is very slow at handling commands.
You need to put a sleep after the command or it get messed.
I use something like this:
siglent.write("INST CH2")
time.sleep(1)
siglent.write("CH2:VOLT 0")
time.sleep(1)
siglent.write("CH2:CURR 1.3")
time.sleep(1)
siglent.write("OUTP CH2, ON")
time.sleep(1)
you can also lower sleep to 0.1 seconds if you need more speedy setup.I guess this is the same problem I found out when I use the USBTMC Linux kernel driver on my PC, and might be really a bad firmware on the power supply. I can lower the delay down to 10 ms and it works always. With 5 ms sometimes it doesn't work. So might be safe to wait 20 ms. The instrument itself seems to be fast. I can do a "CH2:VOLT 9" command and 10 ms later a "CH2:VOLT 8" command and it is set to 8 V.
But I still can't read anything reliably. Could you try this on your system?Code: [Select]print(siglent.ask("*IDN?"))
Sometimes it shows the device, but most of the time it generates an error: "Operation timed out". I tried to edit /opt/python-usbtmc/build/lib.linux-armv7l-2.7/usbtmc/usbtmc.py and insert a time.sleep(0.1) after line 629 in the ask function, between the write and read, and it looks like it helps a bit, but I'm still getting the timeout error often.
At least writing works with the delay. But would have been nice to get the current reading working, too.
Ummmm. I did not use any sleeps in my Rigol DM3068 python script. Right now I'm letting the USB connection run continuously. So far no problems with the python USBTMC.
http://99.232.17.239
Dwaine
Ok, but why does it work sometime and sometimes not with pyusb?
... the pyusb implementation has some other problems, ...
Ummmm. I did not use any sleeps in my Rigol DM3068 python script. Right now I'm letting the USB connection run continuously. So far no problems with the python USBTMC.
http://99.232.17.239
Dwaine