We Keep Coding

Barcode scanners (Netum Scan) in python

I'm writing code which takes input from several barcode scanners, and I want a way to differentiate between each scanner. I'm on windows 10, and my python version is 3.11.1. And as the title suggests, I'm using scanners from a company called Netum.
I've tried using them as HID devices, but this seems incredibly slow and impractical. If the computer sees them each as keyboards, I have to validate each individual keystroke, rather than entire barcodes. So I've abandoned this approach under that assumption.
I discovered these scanners have what's called "USB COM Port Emulation," and that seems promising. It almost never works, but when it does, it just shoves an entire barcode into my code as a string. The problem is that, most of the time, when it's in this mode, it disconnects the USB dongle the instant I scan anything. But it makes a reference to "needing drivers" for this mode. I checked the device manager, which tells me all my drivers are totally up-to-date. This is really the crux of the problem, as my code works if this mode works reliably.
Also, I'm using PySerial to decode the inputs from the scanners. I dunno if that matters, but I figured I'd mention it. The following is the code I'm using to talk to these janky scanners, and it only works when the scanners don't disconnect from my PC for seemingly no reason.
import serial
scanner = serial.Serial(port='COM3', baudrate=9600, bytesize=8, timeout=1, stopbits=serial.STOPBITS_ONE)
string = scanner.read()
print(string.decode())
scanner.close()
If anyone has any advice, insights, or even just general directions to point me in, it would be appreciated. I'm at the point where I don't even know how to begin solving this.

Comment to answer
Have you installed any Virtual Com Port (VCP) drivers such as from FTDI? ftdichip.com/drivers/vcp-drivers They do a executable for easy install - this may help with your stability issues

asciimatics - how to export to a GIF?

I'm new to asciimatics and would like to export animations I'm making to a GIF, at the command line. Note that I want to ONLY record the animation itself, not me starting some command in the terminal to record the gif as well.
I've looked at the docs, but don't see an asciimatics way to do this?
Note that I'm aware of things like ttygif, but tried to use it and couldn't get it to work with asciimatics, probably due to me not understanding how to use it.

You can do this using toughtty - it allows you to control when the recording starts, which works great for staring the recording manually.
My use case is generating fun gifs to paste into Slack that are branded with lol animations and text ;-) So I don't want anyone to actually see it was a terminal window at all, just a retro looking animation that I made super fast!
So in summary:
get your animation ready to record
start the recorder, toughtty by running $ toughtty record frames.json
start your animation. Note that recording hasn't started yet.
once your animation is running, press Ctrl+T to start recording
when you think it's good, press Ctr+C to stop the recording
generate your gif by running toughtty encode --delay 100 out.json test.gif
open the test.gif in your browser to view the animation!
I found toughtty by browsing the active forks of ttystudio
https://techgaun.github.io/active-forks/index.html#chjj/ttystudio
and then installed it under node v8
Example: https://imgur.com/a/0Su6pI6

Raspberry Pi 3: Unusual behaviour with mpd, PiFi DAC+ audio

I'm looking for some help 'cause I'm getting a bit frustrated on this... :-(
I have a headless Raspberry PI 3 with a PiFi DAC+ audio card, basically an HiFiBerry clone. On the PI I installed mpd and mpc as a client.
On top of those I wrote a python script that invokes some mpc commands to control the underlying mpd daemon (load a playlist, play a stream,...).
Now the issue.
The overall audio setup based on the hifiberry-dacplus overlay works well, the sound is good and I'm fine with it. Mpc & mpd work, I can control all the functionalities of mpd (at least the ones I need) through mpc without a flaw...but, if I try to run my python script suddenly I cannot hear anything anymore, even if no specific errors are traced.
The 'scary' thing is that, after aborting the script execution, I'm no more able to play any sound (I tried with several wav files using aplay), and again no specific errors show up in the log files...looks like someone just 'muted' the volume, but alsamixer shows all playback levels to 100%. I need to reboot the PI to get my sound back.
I checked for clues in the usual places:
/var/log/messages
/var/log/syslog
dmesg
boot.log
/var/log/mpd/mpd.log
I also run aplay -vvv when audio was blocked and compared the output with a session where audio was running fine but I didn't notice any difference...
I know it would be very difficult to diagnose the problem without having access to my system, but do you have any ideas on where else to look to understand if something went wrong?
Just for info, here's my aplay -l output:
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ HiFi pcm512x-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
Thank you!
Michele
EDIT: seems like there is some incompatibility between the audio board and a 16x2 LCD display I'm using to show the name of the stream I'm playing. The display is a very common one, based on the HD44780 chip.
My code uses the AdaFruit python library available here to drive it and I still have to figure where the problem is: the audio board, as per HiFiberry docs is connected through GPIO 2,3,18,19,20,21 (plus ground & +5V for power), so it shouldn't cause any conflict with the LCD which uses different pins, but I wouldn't bet on it.
Anyway, removing the LCD management part from the python code (but leaving the display physically attached to the RaspBerry pins) apparently solved the problem...
I'll keep this question updated, maybe could be useful for someone else, who knows!

Ok, I got it. As usual, I just went too fast with CTRL-C & CTRL-V without properly reading the code...
I didn't notice I left this statement in my python code
lcd_backlight = 2 #GPIO pin to control lcd backlight
Actually The GPIO 2 (which is one of the two I2C enabled pins on the Raspberry) is not connected to the LCD, but it is used by the audio board for configuration purposes: this way, whenever I tried to initialize the LCD, the audio board was somehow reconfigured, making it "mute". The only way to reset the faulty configuration was to reboot the PI itself.
Just leaving the default 'None' value for the backlight control pin (I do not need it) did the trick.

"sh: Error: Can't open display" when I try to start a program from python

I have this really strange problem, basically I want to start xpdf (or Libreoffice) from my Python script, that is started by a systemd-service. When I start the script from terminal everything is working fine, but when I plug in my USB device that start the Service, I'll get this Error in my syslog:
sh[2321]: Error: Can't open Display
This error has something to do with X11, that's what my Google searches tell me.
So, my question is: How can I properly run a program like xpdf or libreoffice from Python?
import subprocess
subprocess.call("/usr/bin/xpdf")
This is it, basically. I know that it has something to do with the graphical enviroment, but I don't know how I can solve it.

The X display system has very good security to stop random local processes from just displaying stuff to the local screen (It was more a problem in the old days of expensive Sun and SGI systems where computer labs would often let users telnet to other boxes. Much fun could be had!).
If the user running the xpdf is the same user as the one who's logged into the X session, then you simply need to tell xpdf where to connect it's UI to. This is usually done by exporting DISPLAY=:0 to the environment, which means "connect to the first local screen". Most X programs also support -display :0 argument.
So do:
/usr/bin/xpdf -display :0
or:
DISPLAY=:0 /usr/bin/xpdf
It's very unlikely that you have more than one X session so :0 will work 99% of the time.

Since the issue is that xpdf isn't finding a display to connect to, we have two basic options: find and authenticate with an existing display, or make a new one. The latter is usually easier, something like:
xinit /usr/bin/xpdf -fullscreen $PDFFILE -- :2
This would start a new X display :2 running only xpdf, not even a window manager.

It finally worked, after trying and going crazy for around 2 weeks.
What worked was
os.system("DISPLAY=:0 /usr/bin/xpdf)
I know that subprocess.call is the better way to call the program, but it doesn't seem to work right now.
I'll try the way that Yann suggested later on, but for now I'm just overwhelmed with joy that it just works.
Thank you all for your help, I really appreciate it!

Go Pro Hero 3 - Streaming video over wifi

I recently acquired a Go Pro Hero 3. Its working fine but when i attempt to stream live video/audio it gitches every now and then.
Initially i just used vlc to open the m3u8 file, however when that was glitchy i downloaded the android app and attempted to stream over that.
It was a little better on the app.
I used wireshark and i think the cause of it is its simply not transferring/buffering fast enough. Tried just to get everything with wget in loop, it got through 3 loops before it either: caught up (possible but i dont think so ... though i may double check that) or fell behind and hence timed out/hung.
There is also delay in the image, but i can live with that.
I have tried lowering the resolution/frame rate but im not sure if it is actually doing anything as i can't tell any difference. I think it may be just the settings for recording on the go pro. Either way, it didn't work.
Essentially i am looking for any possible methods for removing this 'glitchiness'
My current plan is to attempt writing something in python to get the files over UDP (no TCP overhead).
Ill just add a few more details/symptoms:
The Go Pro is using the Apple m3u8 streaming format.
At anyone time there are 16 .ts files in the folder. (26 Kb each)
These get overwritten in a loop (circular buffer)
When i stream on vlc:
Approx 1s delay - streams fine for ~0.5s, stops for a little less than that, then repeats.
What i think is happening is the file its trying to transfer gets overwritten which causes it to timeout.
Over the android App:
Less delay and shorter 'timeouts' but still there
I want to write a python script to try get a continuous image. The files are small enough that they should fit in a single UDP packet (i think ... 65Kb ish right?)
Is there anything i could change in terms of wifi setting on my laptop to improve it too?
Ie some how dedicate it to that?
Thanks,
Stephen

I've been working on creating a GoPro API recently for Node.js and found the device very glitchy too. Its much more stable after installing the latest gopro firmware (3.0.0).
As for streaming, I couldnt get around the wifi latency and went for a record and copy approach.