The serial port appears for a single second, and then vanishes before you can upload any code.
This has been happening to me with Pop OS, but apparently also happens with other Ubuntu variants. I can’t believe what the cause is, but if you check dmesg and you will possibly find the following occurring :
[ 98.044600] usb 3-2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice=81.33
[ 98.044606] usb 3-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 98.044607] usb 3-2: Product: USB Serial
[ 98.046052] ch341 3-2:1.0: ch341-uart converter detected
[ 98.046409] usb 3-2: ch341-uart converter now attached to ttyUSB0
[ 98.608979] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input41
[ 98.887664] usb 3-2: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[ 98.888541] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
What we see happening is the OS finds the newly plugged in CH340 based serial device on your board and creates a new serial port, in my case, ttyUSB0. Excellent. But then, along comes “BRLTTY”. BRLTTY has decided it knows what this device is, removes the serial port and turns the device into an input / keyboard device. BRLTTY apparently knows best and claims all devices with the manufacturer / product ID of a USB to UART adapter chip, that is absolutely not always the product they think it is. This is really poor default behaviour, especially as this all happens silently. Apparently BRLTTY is accessibility software for the blind that is installed by default.
To solve the issue, assuming you’re not blind, simply type “sudo apt remove brltty” (without quotes) at the command line and it will be uninstalled, making the issue go away.
Not in Sync
The not in Sync error, where you get a repeated message such as the following :
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
… is an old one with many causes. One cause now seems to be that if you use a clone device, the Arduino IDE refuses to talk to it by default. The solution might be to change the “Processor” in the Tools menu to “ATmega328P (Old Bootloader)”. This would apply to boards such as Unos and Nanos. This might actually also apply to older genuine Arduino Boards.
As you might guess, I’ve had a slightly frustrating day. All I did was try to load a program into a clone board someone gave me the other day.
Very occasionally I find that I need to use a modern pointing device on my retro beige macs through a PCI USB card. An oddity I’ve noticed is that as soon as I touch one of my modern Logitech touchpads, the cursor starts continuously moving to the right. With mice, the behavior is similar, but a little more erratic.
The Solution
Thankfully, there is an easy answer. A little shareware Control Panel called USB Overdrive. This utility is mainly for configuring joysticks and gamepads, but it also offers controls for mice and keyboards. I’ve found that by configuring the mouse settings within USB Overdrive, it fixes the “go to the right” issue with my Logitech devices. I’m uncertain whether the issue exists with other brand’s pointing devices as most of my modern peripherals are Logitech.
USB Overdrive is shareware and can be downloaded from the following site :
https://macintoshgarden.org/apps/usb-overdrive-14
Or locally from here in case the path changes (please use and support Macintosh Garden – remember to contribute any obsolete software you might have on disk which is not already there).
Setup
Once you have installed USB Overdrive on you Mac OS 9.2.2 or older, USB compatible mac, go to the control panel and select an option other than the default “System” from the “Speed” drop down menu. This is all that is needed to fix the bug.
USB Overdrive Screenshot – Image from Macintosh Garden
Notes
If you’re having trouble getting a USB PCI card working, try re-installing your operating system while the card is installed. By default the system installers do not include the required USB drivers unless they find the hardware. A fresh install can massively help with troubleshooting. USB got more reliable with time I believe it was first introduced for Mac OS 8.1 (for the iMac), but functions progressively better in newer versions up to 9.2.2.
While most USB PCI cards “just work” in beige macs, it is widely reported that the most stable and reliable cards are those that use the OPTi chipset and have two USB ports. This is the same chipset as was used in Macs with built in USB and so is the best supported.
A little while ago, I bought myself a Economatics Smart Box (SB-04). My intention is to reverse engineer the serial protocol so that I can use it from a modern (Linux, but the information will be useful to others) computer. These boxes were common in schools in the UK through the 90s (and possibly before). Older variants worked with the BBC Micro. This is what they look like if anyone has forgotten or hasn’t seen one before :
A couple of minor issues so far – Number 1 – This specific model (the SB-04) doesn’t have mains in like some of the older versions, it has 12v AC in – don’t know about you, but I’ve hardly seen any AC-AC PSUs in years.
I’m aware that often you can just use a DC PSU of the same voltage with such equipment because the first thing that happens on the circuit board is that the supply is rectified and smoothed… using a DC supply just means that the supply is always going through two of the diodes and the capacitor remains permanently charged. As long as you’re within the diode ratings and the resultant voltage is close enough, there isn’t an issue. My thought was to check the circuit and see if there was any obvious reason why this wouldn’t work, which is where we get to issue Number 2…
Anti-tamper screws. I managed to get these out using a tiny socket and pushing down hard.
Lovely looking PCB inside designed by “G A Assembly Ltd” and “Mindstorm” (I wonder if there is any connection to the Lego Mindstorm?). Note one bodge wire, a socketed chip with the firmware version (with an unusual pitch), a missing MAX4622 chip (single pole double throw fast acting switch https://www.maximintegrated.com/en/prod … X4622.html) and space for a USB B socket. The digital outputs are buffered with ULN2064b chips (these are darlington pair arrays).
Anyway, I’ve got distracted.
First point – there is no obvious rectifier, the PSU portion of the circuit is complex and includes two large inductors by the look of it. I’ll have to do a bit more digging and look up what some of the components are.
Second most important point – does anybody have a photo of the USB version of this board – I’d be interested in adding USB if I can. Current theory – the bodge wire is hardwiring my board to Serial and saving the need for the MAX4622 chip for switching between USB and RS232. There are a bank of jumpers that look interested and are next to the USB lines. I’m also wondering is the firmware the same in the USB and Serial variants?
Photos of the top side of the PCB (actually the bottom as it sits on the desk) for interest.
I think the main chip might be some kind of 6502 based MCU or similar – I can’t find a good datasheet online that exactly matches. It has a reduced pin pitch, 42 pins and it looks like the Crystal is connected to pins 19 and 20.
A 6502 based MCU would make sense given that the company made BBC Micro peripherals.
Older versions of the board are basically an embedded 6502 computer with RAM, ROM, an ADC and a VIA. My newer version is based on a Mitsubishi microcontroller, the M37536E8SP.
I’ve taken the board completely out of the case now. No components on the reverse, but useful for tracking traces. I’ve also noticed that there is a cut trace next to the test point that the bodge wire is attached to (separating it from a capacitor that looks like it is attached to a power rail judging by the track width – they must have accidentally tied it high).
Underside of the PCB :
Thoughts welcome, photos of the USB variant would be gratefully received!
Update – Some progress. I have digital write working from Python. I was lucky enough to find this page, which includes a download of sample code for controlling the Smart Box from VB6. Helpfully, this includes a number of the serial commands for making the box do various things. I’ve been able to extract the commands for the core functionality.
A while back I wrote a post about using an FTDI breakout board as a GPIO board from Python. Since then, I have discovered that there are USB relay boards based on this concept available from China. SainSmart seem to sell them, but they are available on ebay, Banggood and Aliexpress. The boards are interesting as they do not contain a microcontroller – just an FTDI chip and an ULN2803 array of Darlington pairs to drive the relay coils.
SainSmart 8 Channel USB Relay Board
Using the setup previously detailed in my other post, it is possible to control one of these boards from Linux. The process is exactly the same as using one of the little red USB UART adapter boards.
Plug the board into a 12v DC supply, and your computer’s USB.
Run the following example (as root / with sudo if you haven’t set up permissions for your user to access the device).
#!/usr/bin/env python
import os
import sys
import ftdi1 as ftdi
import time
ftdic = ftdi.new()
if ftdic ==0:
print( 'new failed: %d', ret )
os._exit( 1 )
# try to list ftdi devices 0x6010 or 0x6001
ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6010 )
if ret <= 0:
ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6001)
if ret < 0:
print( 'ftdi_usb_find_all failed: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
os._exit( 1 )
print( 'Number of FTDI devices found: %d\n' % ret )
curnode = devlist
i = 0
while( curnode != None ):
ret, manufacturer, description, serial = ftdi.usb_get_strings( ftdic, curnode.dev )
if ret < 0:
print( 'ftdi_usb_get_strings failed: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
os._exit( 1 )
print( 'Device #%d: manufacturer="%s" description="%s" serial="%s"\n' % ( i, manufacturer, description, serial ) )
curnode = curnode.next
i += 1
# open usb
ret = ftdi.usb_open( ftdic, 0x0403, 0x6001 )
if ret < 0:
print( 'unable to open ftdi device: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
os._exit( 1 )
# bitbang
ret = ftdi.set_bitmode( ftdic, 0xff, ftdi.BITMODE_BITBANG )
if ret < 0:
print( 'Cannot enable bitbang' )
os._exit( 1 )
for i in range( 8 ):
val = 2**i
#print( 'enabling bit #%d (0x%02x)' % (i, val) )
ftdi.write_data( ftdic, chr(val), 1 )
time.sleep ( 0.5 )
ftdi.write_data( ftdic, chr(0x00), 1)
time.sleep ( 0.2 )
ftdi.disable_bitbang( ftdic )
print( '' )
# close usb
ret = ftdi.usb_close( ftdic )
if ret < 0:
print( 'unable to close ftdi device: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
os._exit( 1 )
print ('device closed')
ftdi.free( ftdic )
This code is lightly modified from the code found here, without which I’d have struggled.
HID USB Relay Board
Similar boards exist which use an Atmel microcontroller interfacing with the computer through a software HID implementation. These boards are cheaper, but otherwise similar on the relay side and in appearance.
Red USB Relay Board
These boards can be controlled from Linux by installing the “usbrelay” program from the repository (on Ubuntu and Debian at least) using “sudo apt-get install usbrelay”. Otherwise the developer has a github page for the project here : https://github.com/darrylb123/usbrelay. Once installed and with the device connected, simply typing “sudo usbrelay” (without quote marks) at your command line reports back on connected devices. One of my devices calls itself “VXCMF”, while another calls itself “6QMBS”. Where a device is called “VXCMF”, the first two relays can be turned on with the following command “sudo usbrelay VXCMF_1=1 VXCMF_2=1” and off again with “sudo usbrelay VXCMF_1=0 VXCMF_2=0”.
If you want to use the boards without sudo, you’ll have to add it to /etc/udev/rules.d. There are detailed instructions on the github linked above, but in short, if you’re using a Debian family OS, put the following in a file called “50-usbrelay.rules” in the folder /etc/udev/rules.d :
Then make sure your user is in the plugdev group and restart. If you’re using Windows or macOS, there are other instructions in forks such as this one https://github.com/corerd/usbrelay, although it looks a little old.
Both boards detailed in this post are available with various numbers of relays. The red boards are probably easier to use as it is simply a case of installing usbrelay. Hopefully the instructions here and in my previous post can help people get their boards running. I haven’t tested, but both should work fine with a Raspberry Pi and many other SBCs.