Quantcast

Reading DMX

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Reading DMX

E.S. Rosenberg
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]



serial_test.c (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

E.S. Rosenberg

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

Ryan Tennill
I can't comment on the DMX issue but here's a handy page for the flow control signals:
http://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04flowctl.htm

RTS/CTS and DTR/DSR are harware signals where as XON/XOFF usually fall under 'software' flow control. I have only used RTS/CTS on the FT23R to date. I don't know if there's a particular reason to use DTR/DSR vs RTS/CTS unless you're interfacing with some legacy hardware that uses it.

Ryan

On 5/8/2014 5:29 PM, E.S. Rosenberg wrote:

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]





libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

E.S. Rosenberg
2014-05-09 7:28 GMT+03:00 Ryan Tennill <[hidden email]>:
I can't comment on the DMX issue but here's a handy page for the flow control signals:
http://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04flowctl.htm

RTS/CTS and DTR/DSR are harware signals where as XON/XOFF usually fall under 'software' flow control. I have only used RTS/CTS on the FT23R to date. I don't know if there's a particular reason to use DTR/DSR vs RTS/CTS unless you're interfacing with some legacy hardware that uses it.
Thanks, that was very useful!
I am communicating using EIA-485 as physical layer but DMX-512A has no concept of flowcontrol so setting it to off and RTS to off seems to be the correct thing.

I started looking at the stream reading example figuring that maybe that way I'd do the Break/MAB detection on the host but it seems the FT4232HQ doesn't support synchronous FIFO mode....
Either way the break/MAB do seem to be detected properly since as far as I can tell they don't add data (gibberish) to the captured data, it's just that I lack a way of reading instantly the moment a break is reached (and consequentially a whole packet is in the buffer).

Thanks so far,
Eli

Ryan


On 5/8/2014 5:29 PM, E.S. Rosenberg wrote:

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]





libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]





libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

Rui Barreiros
In reply to this post by E.S. Rosenberg
Hi,

I was never able to solve that issue, I just gave up on reading DMX with any FTDI device using software and went the MCU path by using AVR (that particular project was an ATMega8).

The problem was not chip specific in my case, because in windows using FTDI  D2XX direct driver implementation over windows I managed to properly parse the DMX signal and read it without any complication, but since I needed it to work under linux I had to abandon it and go the MCU route.

I didn't research enough to figure out where the problem lies (libusb, libftdi, etc) due to time constraints.

Good luck.

On 05/08/2014 11:29 PM, E.S. Rosenberg wrote:

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]




--

Rui Barreiros
[hidden email]
Tlm: +351 962 356 020
Rua Alminhas das Cais, 950
4410-497 Serzedo VNG
Portugal
NIF: 506 107 523
Tlm: +351 968 015 215
Tlf: +351 227 625 805
Fax: +351 227 534 304
[hidden email]




libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

E.S. Rosenberg
2014-05-09 12:25 GMT+03:00 Rui Barreiros <[hidden email]>:
Hi,

I was never able to solve that issue, I just gave up on reading DMX with any FTDI device using software and went the MCU path by using AVR (that particular project was an ATMega8).

The problem was not chip specific in my case, because in windows using FTDI  D2XX direct driver implementation over windows I managed to properly parse the DMX signal and read it without any complication, but since I needed it to work under linux I had to abandon it and go the MCU route.
Hi Rui,
Thanks for the response! I asked on the OLA IRC channel if someone had your details but this also works :)

I didn't research enough to figure out where the problem lies (libusb, libftdi, etc) due to time constraints.
What you say here at least already helps a lot because it means it's something in libftdi/libusb/linux and that it's something we can fix...

Good luck.
Thanks!
Eli


On 05/08/2014 11:29 PM, E.S. Rosenberg wrote:

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]




--

Rui Barreiros
[hidden email]
Tlm: <a href="tel:%2B351%20962%20356%20020" value="+351962356020" target="_blank">+351 962 356 020
Rua Alminhas das Cais, 950
4410-497 Serzedo VNG
Portugal
NIF: 506 107 523
Tlm: <a href="tel:%2B351%20968%20015%20215" value="+351968015215" target="_blank">+351 968 015 215
Tlf: <a href="tel:%2B351%20227%20625%20805" value="+351227625805" target="_blank">+351 227 625 805
Fax: <a href="tel:%2B351%20227%20534%20304" value="+351227534304" target="_blank">+351 227 534 304
[hidden email]




libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]





libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

E.S. Rosenberg
When I have time I would like to see what causes this problem (bug?), but I have no experience with this type of debugging so I would very much appreciate it if people with more experience on this list can give pointers.

Currently I assume I will download FTD2XX and compile against it and run both libftdi and FTD2XX through gdb and try to find differences (hoping that they haven't obfuscated/optimized out the needed debug info), but if there are better methods...

Thanks,
Eli


2014-05-09 13:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
2014-05-09 12:25 GMT+03:00 Rui Barreiros <[hidden email]>:

Hi,

I was never able to solve that issue, I just gave up on reading DMX with any FTDI device using software and went the MCU path by using AVR (that particular project was an ATMega8).

The problem was not chip specific in my case, because in windows using FTDI  D2XX direct driver implementation over windows I managed to properly parse the DMX signal and read it without any complication, but since I needed it to work under linux I had to abandon it and go the MCU route.
Hi Rui,
Thanks for the response! I asked on the OLA IRC channel if someone had your details but this also works :)

I didn't research enough to figure out where the problem lies (libusb, libftdi, etc) due to time constraints.
What you say here at least already helps a lot because it means it's something in libftdi/libusb/linux and that it's something we can fix...

Good luck.
Thanks!
Eli


On 05/08/2014 11:29 PM, E.S. Rosenberg wrote:

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]




--

Rui Barreiros
[hidden email]
Tlm: <a href="tel:%2B351%20962%20356%20020" value="+351962356020" target="_blank">+351 962 356 020
Rua Alminhas das Cais, 950
4410-497 Serzedo VNG
Portugal
NIF: 506 107 523
Tlm: <a href="tel:%2B351%20968%20015%20215" value="+351968015215" target="_blank">+351 968 015 215
Tlf: <a href="tel:%2B351%20227%20625%20805" value="+351227625805" target="_blank">+351 227 625 805
Fax: <a href="tel:%2B351%20227%20534%20304" value="+351227534304" target="_blank">+351 227 534 304
[hidden email]




libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]






libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reading DMX

E.S. Rosenberg
I have been doing some reading of libftdi source, libusb docs, usb primer and FTDI docs and I gathered the following:
FTDI :
- The device will copy the contents of the readbuffer to the computer when the line state changes (BREAK) or when the buffer is full.
libftdi:
- uses libusb_fill_bulk_transfer() or libusb_bulk_transfer_submit(), both will start trying to fullfill the data request regardless of the 'stage' of reception and will continue until the length requested is fullfilled, again regardless of actual packet length.
libusb:
- has libusb_fill_interrupt_transfer() for interrupt transfers (http://www.beyondlogic.org/usbnutshell/usb4.shtml)

I may be wrong but it sounds to me like for this case interrupt transfers would be ideal since they should happen whenever a brake comes along regardless of whether or not the broadcasting party was sending a 513 byte packet or just a 25 byte packet.

Has anyone ever played with the interrupt transfer instead of bulk transfers?
Or am I bending a standard to something it is not....?

Thanks for the help & input,
Eli



2014-05-10 20:53 GMT+03:00 E.S. Rosenberg <[hidden email]>:
When I have time I would like to see what causes this problem (bug?), but I have no experience with this type of debugging so I would very much appreciate it if people with more experience on this list can give pointers.

Currently I assume I will download FTD2XX and compile against it and run both libftdi and FTD2XX through gdb and try to find differences (hoping that they haven't obfuscated/optimized out the needed debug info), but if there are better methods...

Thanks,
Eli


2014-05-09 13:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:

2014-05-09 12:25 GMT+03:00 Rui Barreiros <[hidden email]>:

Hi,

I was never able to solve that issue, I just gave up on reading DMX with any FTDI device using software and went the MCU path by using AVR (that particular project was an ATMega8).

The problem was not chip specific in my case, because in windows using FTDI  D2XX direct driver implementation over windows I managed to properly parse the DMX signal and read it without any complication, but since I needed it to work under linux I had to abandon it and go the MCU route.
Hi Rui,
Thanks for the response! I asked on the OLA IRC channel if someone had your details but this also works :)

I didn't research enough to figure out where the problem lies (libusb, libftdi, etc) due to time constraints.
What you say here at least already helps a lot because it means it's something in libftdi/libusb/linux and that it's something we can fix...

Good luck.
Thanks!
Eli


On 05/08/2014 11:29 PM, E.S. Rosenberg wrote:

2014-05-09 1:27 GMT+03:00 E.S. Rosenberg <[hidden email]>:
Hi all,

Several years ago Rui Barreiros already posted a question on the subject which at the time doesn't seem to have been resolved and I am running into the same problem more or less:

The DMX packet is read but ends up shifted over different amounts of bit every read.

I currently suspect that this is all dependent on when the OS issues the ftdi_read_data() call, I suspect this because when I ran my test program using gdb the shifts were a lot more extreme (almost 0.5 packet) then when it was running directly.

The packet itself is basically:
1. BREAK (>= 88us of LOW)
2. MAB (>= 8us HIGH)
3. 25-513 data slots (1b start HIGH, 8b data, 2b STOP HIGH each)

So my question is: Is there any way to 'allign' the reads to the break+mab?

attached is my modified version of the serial_test.c example.

Side questions:
- Can someone on the list explain the different flow control options?
- What is the RTS?

Thanks,
Eliyahu - אליהו

The device I am using is a USB-COM485-Plus4

Thanks,
Eli


libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]




--

Rui Barreiros
[hidden email]
Tlm: <a href="tel:%2B351%20962%20356%20020" value="+351962356020" target="_blank">+351 962 356 020
Rua Alminhas das Cais, 950
4410-497 Serzedo VNG
Portugal
NIF: 506 107 523
Tlm: <a href="tel:%2B351%20968%20015%20215" value="+351968015215" target="_blank">+351 968 015 215
Tlf: <a href="tel:%2B351%20227%20625%20805" value="+351227625805" target="_blank">+351 227 625 805
Fax: <a href="tel:%2B351%20227%20534%20304" value="+351227534304" target="_blank">+351 227 534 304
[hidden email]




libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]







libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]


Loading...