USB connection fail with usb-serial

[Paul Drage]

I've been running a raspberry pi with ola, talking to another pi with a dmx card with USB, running Arjan's bare metal rdm code, and recently also an arduino with dmx shield acting as an rdm device.  All was well until the ola pi had  major issue and wouldnt restart, so I had to rebuild a new SD card from scratch.

I have build a 0.10.6 system, which seems to be mostly OK, but communicate with the arjan code Pi. The relevant bit of the log file seems to look like this:


Feb 25 17:23:24 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/ttyUSB0
Feb 25 17:23:24 raspberrypi olad: common/io/Serial.cpp:197: Acquired /var/lock/LCK..ttyUSB0
Feb 25 17:23:24 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:384: trying stage 0 for 0xe52730
Feb 25 17:23:25 raspberrypi olad: plugins/usbpro/UsbProWidgetDetector.cpp:323: USB Widget didn't respond to messages, esta id 0, device id 0
Feb 25 17:23:25 raspberrypi olad: plugins/usbpro/UsbProWidgetDetector.cpp:326: Is device in USB Controller mode if it's a Goddard?
Feb 25 17:23:25 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:384: trying stage 1 for 0xe52730
Feb 25 17:23:25 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:381: no more detectors to try for  0xe52730
Feb 25 17:23:25 raspberrypi olad: common/io/Serial.cpp:245: Released /var/lock/LCK..ttyUSB0
Feb 25 17:23:27 raspberrypi olad: olad/plugin_api/Universe.cpp:286: Added source client, 0xe1b6b0 to universe 1
Feb 25 17:23:43 raspberrypi olad: olad/plugin_api/Universe.cpp:439: Removed Stale Client
Feb 25 17:23:47 raspberrypi olad: olad/plugin_api/Universe.cpp:286: Added source client, 0xe1b6b0 to universe 1

I've tried blacklisting ftdi_sio, but nothing seems to make any difference.

Is there something obvious that I've missed?

[Arjan van Vught]

Op 25 feb. 2018 om 18:42 heeft 'Paul Drage' via open-lighting <open-l...@googlegroups.com> het volgende geschreven:

Feb 25 17:23:25 raspberrypi olad: plugins/usbpro/UsbProWidgetDetector.cpp:323: USB Widget didn't respond to messages, esta id 0, device id 0

Hi Paul, the above tells me that there is no connection between the OLA server and the USB Widget. I have added a sample log below. What is your configuration for the USB Serial plug-in?

Greets, Arjan

olad/PluginManager.cpp:195: Trying to start Serial USB
common/thread/Thread.cpp:194: Thread , policy SCHED_OTHER, priority 0

plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/ttyUSB0

common/io/Serial.cpp:197: Acquired /var/lock/LCK..ttyUSB0
plugins/usbpro/WidgetDetectorThread.cpp:384: trying stage 0 for 0x73e00548
olad/PluginManager.cpp:200: Started Serial USB
plugins/usbpro/UsbProWidgetDetector.cpp:536: Detected USB Device: ESTA Id: 0x7ff0 (AvV), device Id: 0x0001 (Raspberry Pi DMX USB Pro), serial: 0xebf43844, f/w version: 2.4
plugins/usbpro/WidgetDetectorThread.cpp:314: Defaulting to a Usb Pro device
olad/plugin_api/DeviceManager.cpp:105: Installed device: AvV - Raspberry Pi DMX USB Pro, Serial #: 1511543844, firmware 2.4:5-1511543844

[Peter Newman]

I don't think there can be "no connection" Arjan, or it wouldn't acquire the lock and try and talk to it (Stage 0).

But I'd agree, ensure the usbserial plugin is turned on and Stageprofi/ftdidmx/opendmx are disabled and see how you get on Paul.

To me it looks like Arjan's bare metal code isn't responding correctly/at all.

The output of lsusb -v would also be helpful.

On Sunday, 25 February 2018 18:09:11 UTC, Arjan van Vught wrote:

[Paul Drage]

Here are the lsusb -v log file and the ola-serial.conf file. The only plugins that are enabled are artnet, E1.31, uart native dmx and serial usb

I've just looked at syslog again.. When I plug the USB widget in, it says:
Feb 25 19:28:41 raspberrypi kernel: [   47.684495] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
Feb 25 19:28:41 raspberrypi kernel: [   47.812224] usb 1-1.4: New USB device found, idVendor=0403, idProduct=6001
Feb 25 19:28:41 raspberrypi kernel: [   47.812251] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 25 19:28:41 raspberrypi kernel: [   47.812268] usb 1-1.4: Product: FT245R USB FIFO
Feb 25 19:28:41 raspberrypi kernel: [   47.812283] usb 1-1.4: Manufacturer: FTDI
Feb 25 19:28:41 raspberrypi kernel: [   47.812298] usb 1-1.4: SerialNumber: A5054V81
Feb 25 19:28:41 raspberrypi kernel: [   47.823118] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Feb 25 19:28:41 raspberrypi kernel: [   47.823306] usb 1-1.4: Detected FT232RL
Feb 25 19:28:41 raspberrypi kernel: [   47.824385] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
Feb 25 19:28:57 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/ttyUSB0

This seems to be using ftdi_sio. I believe thats not right, but if I blacklist the ftdi_sio driver, then /dev/ttyUSB0 isnt getting created.  Do I need to add a udev rule or something so that I can blacklist ftdi_sio, but keep /dev/ttyUSB0 being created?
 

[Peter Newman]

That's probably a question for Arjan sorry. My DMXKing USB Pro equivalent uses the ftdi_sio driver on (non Pi) Linux; sorry I'm too lazy to go upstairs and get the genuine Enttec. Where did you read you shouldn't use the sio driver? Unfortunately I can't see anything relevant on his site.

The logging to me still suggests it's not responding to the Enttec messages. Can you try launching olad with -l 4 (or relaunching if it's already running), and the rest of the parameters the same and you should get a lot more logging of what's going on.

What output do you get from the Enttec Pi on it's HDMI output, I believe there should be some debugging?

[Arjan van Vught]

Op 26-2-2018 om 0:27 schreef Peter Newman:

That's probably a question for Arjan sorry. My DMXKing USB Pro equivalent uses the ftdi_sio driver on (non Pi) Linux; sorry I'm too lazy to go upstairs and get the genuine Enttec. Where did you read you shouldn't use the sio driver? Unfortunately I can't see anything relevant on his site.

For reference, herewith my /var/log/messages
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.384008] usb 1-1.4: new full-speed USB device number 6 using dwc_otg
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.541589] usb 1-1.4: New USB device found, idVendor=0403, idProduct=6001
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.541604] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.541612] usb 1-1.4: Product: FT245R USB FIFO
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.541619] usb 1-1.4: Manufacturer: FTDI
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.541627] usb 1-1.4: SerialNumber: A8021F6Z
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.549964] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.550169] usb 1-1.4: Detected FT232RL
Feb 26 16:21:45 openlighting-3 kernel: [ 1151.551100] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0

and pi@openlighting-3:~/.ola $ cat ola-usbserial.conf
device_dir = /dev
device_prefix = ttyUSB
enabled = true
pro_fps_limit = 190
tri_use_raw_rdm = false
ultra_fps_limit = 40

all other USB related plug-ins are disabled.

The logging to me still suggests it's not responding to the Enttec messages. Can you try launching olad with -l 4 (or relaunching if it's already running), and the rest of the parameters the same and you should get a lot more logging of what's going on.

@Paul, you mentioned that it worked before. Are there any differences with the new setup compared with the previous?

What output do you get from the Enttec Pi on it's HDMI output, I believe there should be some debugging?

With a default configuration there is limited output. However, it shows the Enttec Label messages. The example below shows the RDM Timeout (Label=12, length=0) returned on the RDM Discovery Request (Label=11). There are no RDM Responders connected.

- Arjan

On Sunday, 25 February 2018 19:31:55 UTC, Paul Drage wrote:

Here are the lsusb -v log file and the ola-serial.conf file. The only plugins that are enabled are artnet, E1.31, uart native dmx and serial usb

I've just looked at syslog again.. When I plug the USB widget in, it says:
Feb 25 19:28:41 raspberrypi kernel: [   47.684495] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
Feb 25 19:28:41 raspberrypi kernel: [   47.812224] usb 1-1.4: New USB device found, idVendor=0403, idProduct=6001
Feb 25 19:28:41 raspberrypi kernel: [   47.812251] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 25 19:28:41 raspberrypi kernel: [   47.812268] usb 1-1.4: Product: FT245R USB FIFO
Feb 25 19:28:41 raspberrypi kernel: [   47.812283] usb 1-1.4: Manufacturer: FTDI
Feb 25 19:28:41 raspberrypi kernel: [   47.812298] usb 1-1.4: SerialNumber: A5054V81
Feb 25 19:28:41 raspberrypi kernel: [   47.823118] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Feb 25 19:28:41 raspberrypi kernel: [   47.823306] usb 1-1.4: Detected FT232RL
Feb 25 19:28:41 raspberrypi kernel: [   47.824385] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
Feb 25 19:28:57 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/ttyUSB0

This seems to be using ftdi_sio. I believe thats not right, but if I blacklist the ftdi_sio driver, then /dev/ttyUSB0 isnt getting created.  Do I need to add a udev rule or something so that I can blacklist ftdi_sio, but keep /dev/ttyUSB0 being created?
 

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Paul Drage]

my ola-usbserial is now the same as your version. It had a few extra device_prefix lines, but those are now removed.

 My /var/log/messages looks just like yours above, but then goes on to say:
USB Widget didn't respond to messages, esta id 0, device id 0 (file attached)

The HDMI output from the widget looks like this

Could i be looking in the wrong place here? Should I be rebuilding the widget code instead?  If so, is there a good set of instructions to build the SD card? I think I did it by trial and error the first time

[Arjan van Vught]

Op 26-2-2018 om 22:24 schreef 'Paul Drage' via open-lighting:

Could i be looking in the wrong place here? Should I be rebuilding the widget code instead?  If so, is there a good set of instructions to build the SD card? I think I did it by trial and error the first time

Looking at your HDMI output, then you are running V1.4 on a Raspberry Pi Model 3. With V1.8 there is "Bug fixed timing issue with FT245RL on Raspberry Pi Model 3".
There is a direct link to the SDCard on http://www.raspberrypi-dmx.org/raspberry-pi-rdm-controller
Just unzip that file to an empty SDCard and it is plug 'n play with the defaults.

Please note that using a Raspberry Pi Model 3 (/2) is overkill. This application is typically targeted for a Raspberry Pi Model Zero (/A+).

Greets, Arjan

[Paul Drage]

OK, So I've built a new USB Widget SD Card, but Its still doing the same thing.  The HDMI output on the widget says:

[v2.0] Pi 3 Model B 1GB v1.2 Compiled on Dec 31 2017 at 14:18:28

RDM Controller with USB [Compatible with Entec USB Pro protocol], Widget mode : 0 (DMX_RDM)

Device UUID: 7ff0:ebb3a3aa, Label: Raspberry Pi DMX USB Pro

with nothing else on the screen with this version.

and the Ola machine is still saying:
Feb 27 20:49:47 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/ttyUSB0
Feb 27 20:49:47 raspberrypi olad: common/io/Serial.cpp:197: Acquired /var/lock/LCK..ttyUSB0
Feb 27 20:49:47 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:384: trying stage 0 for 0x18e0f10
Feb 27 20:49:47 raspberrypi olad: plugins/usbpro/UsbProWidgetDetector.cpp:323: USB Widget didn't respond to messages, esta id 0, device id 0
Feb 27 20:49:47 raspberrypi olad: plugins/usbpro/UsbProWidgetDetector.cpp:326: Is device in USB Controller mode if it's a Goddard?
Feb 27 20:49:47 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:384: trying stage 1 for 0x18e0f10
Feb 27 20:49:47 raspberrypi olad: plugins/usbpro/WidgetDetectorThread.cpp:381: no more detectors to try for  0x18e0f10
Feb 27 20:49:47 raspberrypi olad: common/io/Serial.cpp:245: Released /var/lock/LCK..ttyUSB0

Is there anything else I can look at on the USB traffic to see if anything obvious  is going wrong there?

--

The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

[Arjan van Vught]

Hi Paul,

I have tried to re-create your issue with building a similar environment;  OLA server 0.10.6 on a Raspberry Pi 3 with Raspbian Stretch; USB Widget on Raspberry Pi 3 with V2.0 of the baremetal code.
It is working fine for me. I noticed that Rogier (BitWizard) contacted you directly and that you are going to rebuild the Raspbian environment.
Please let us know the outcome.

Thanks, Arjan

Op 27-2-2018 om 21:58 schreef 'Paul Drage' via open-lighting:

To unsubscribe from this group, send email to open-lightin...@googlegroups.com

[Paul Drage]

Hi Arjan,

I've managed to work out what the problem was. It was a bad connection between the DMX card and the rPi.  I took the connectors apart (there is a short connector and and intermediate one ), and turned the intermediate one around so that any bad connection would move, and then it all started working.

So, I've now got a 0.10.6 ola build, a v2.0 widget, and an arduino clone with DMX card running an RDM receiver all working together. Looks like I need to make sure that the DMX card and rPi in my Widget are securely fixed together rather than trusting in the connector support its own weight.

Thanks for your help, and sorry that it was something so simple in the end.

At least I've learnt how to use Wireshark to sniff USB data as part of this process.

Regards,
Paul Drage

[Peter Newman]

Hi Paul,

That's good, glad to hear you got it sorted.

Arjan, I wonder if it's possible to add a debug mode to your software which would show the incoming packets on the USB side and hence might help to diagnose this sort of issue?

[Arjan van Vught]

Op 3-3-2018 om 5:03 schreef Peter Newman:

Hi Paul,

That's good, glad to hear you got it sorted.

Arjan, I wonder if it's possible to add a debug mode to your software which would show the incoming packets on the USB side and hence might help to diagnose this sort of issue?

Hi Peter, per default the software is showing the received label and the response data length. See example below. As there was no label showing at all for Paul, it was telling that there was no communication between the Raspberry Pi GPIO's and the FT245RL.
There is an undocumented (http://www.raspberrypi-dmx.org/raspberry-pi-rdm-controller/configuration) parameter : device_external_monitor
It is defaulted to 0, which means showing the received label only. When set to 1 (device_external_monitor=1) then both DMX and RDM data are shown. When set to 2 (or higher), then the local time and up-time are shown as well.

Greets, Arjan
http://www.raspberrypi-dmx.org/
 

[Arjan van Vught]

Hi Paul, good to read that it is all working fine now.

In order to prevent such a mechanical connector failure, I am in favor
of using the Zero on top of a DMX/RDM board,  for example ->
https://github.com/vanvught/rpidmx512/tree/master/rpi_dmx_usb_pro

Thanks, Arjan
http://www.raspberrypi-dmx.org/

Op 2-3-2018 om 21:59 schreef 'Paul Drage' via open-lighting: