Problem with CBus Module through USB

Discussion in 'General Discussion' started by AlexeyR, Mar 12, 2010.

  1. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    Hello,

    I have a laptop with Debian Squeeze (Linux kernel 2.6.33) and I've been trying to contact and control CBus devices using the CBus module from Sourceforge. Since I have no RS232, was trying to use USB by connecting to ttyUSB0, with USB PCI on the CBus side. It all looked fine at first, command line example printed all the changes in network, but then I discovered some strange things:
    If there are no events from CBus network for 40 seconds, any new events don't come through, as if USB port went to sleep. Though CBM shows connected state.
    Also, changing Lighting level of any group does change it's level in Module's database, but has no effect on the actual level in network. Like if it never made it through.

    According to dmesg, USB is set up with cp210x converter, meaning it's working as USB to COM.
    Can anyone advise on where should I look?

    Thank you in advance.
     
    AlexeyR, Mar 12, 2010
    #1
    1. Advertisements

  2. AlexeyR

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,363
    Likes Received:
    10
    Location:
    Adelaide, South Australia
    Sounds like the virtual COM port driver you are using is dodgy. Seek out an upgrade. If that fails, contact Silicon Labs and ask them to fix it.
     
    ashleigh, Mar 12, 2010
    #2
    1. Advertisements

  3. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    Well, I have the latest kernel, driver's inside, I assume it's default and also latest.

    Have you tested USB connection under Linux? If so, maybe I could try and install the OS you had and see if anything changes? If you can tell me which one worked.

    Though I've already tested it on 2 laptops, running AMD64 and i386 Debian Squeeze with 3 different kernels, results were all the same.

    I've found a laptop with RS232, but I have no COM CBus PCInt, only USB one and a BW TouchScreen, that does not show as PCInt to CBM. It requires different signal to set it as PCint?
     
    AlexeyR, Mar 13, 2010
    #3
  4. AlexeyR

    Darren Senior Member

    Joined:
    Jul 29, 2004
    Messages:
    2,361
    Likes Received:
    0
    Location:
    Adelaide, South Australia
    A C-Touch (Mark 1) should operate as an RS232 PC Interface. The C-Bus Module (and other C-Bus software) sends a "~~~" command to initialise the PC Interface. The C-Touch sees this and puts itself into a PC Interface emulation mode.
     
    Darren, Mar 14, 2010
    #4
  5. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    The problem seems to be in the ping requests from CBM to PCI. Tested on USB and COM PCI. Network consists of 2 PCI, Power Supply module and a BusCoupler with 1 group on it.
    CBM does voltage checks every 4 seconds if there's no activity:
    @2107D8t
    Most of the time answer is like:
    t.86F0F000860733322E3056F4
    But once in a while answer comes:
    F0F000860733322E3056F4
    or
    F000860733322E3056F4
    or
    .86F0F000860733322E3056F4
    Then CBM sets state ping_failed and gets stuck in an infinite loop(?).
    I've made it close connection and reconnect, if ping fails, now it does not get stuck. Ping fails every ~40-100 seconds and I have no idea what causes the loss of first bytes. Overflow would've normally cut off the tail, not head.
    At the same time MMI messages come through with no losses.
    Anyone know what may cause such losses? It's always head of ping reply, that's getting lost.
     
    Last edited by a moderator: Mar 15, 2010
    AlexeyR, Mar 15, 2010
    #5
  6. AlexeyR

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,363
    Likes Received:
    10
    Location:
    Adelaide, South Australia
    Are you attaching this to a din-rail (or other) PCI?

    If you are, can you find out (using Toolkit) the firmware version number of that PCI, please.
     
    ashleigh, Mar 15, 2010
    #6
  7. AlexeyR

    Matty

    Joined:
    Oct 15, 2004
    Messages:
    131
    Likes Received:
    0
    Hi AlexeyR,

    It looks like the responses you're getting occasionally have a few bytes at the front chopped off.
    We don't have an official recommendation for the linux distribution you should be using. I believe the 2 most popular distro's are (1) Ubuntu and (2) Fedora.

    I'm assuming that the messages from the USB PCI you've listed below have been intercepted by you before they are passed in the CBM. It sounds like the problem is occurring somewhere in the linux kernel or silicon labs driver.

    Can you tell me what version of the silicon labs driver you're using?
    After ~40 seconds when this problem starts occurring do you still see correct MMI's every 3 seconds?
    If you toggle a lighting group on C-Bus do you see this messages correctly received by the CBM?

    Since you have a C-Touch you could do the following test to prove whether the problem exists in the silicon labs driver.
    1. get a USB to serial converter (we recommend a dontronics)
    2. connect the the C-Touch RS232 to your brand spanking new dontronics converter.
    3. Change your code to talk to a com port instead or a USB device.
    4. run your test for more than 100 seconds.

    If you no longer have the problem then its the silicon labs driver. If the problem still exists then the problem may be due to linux.

    Regards,

    Matty
     
    Matty, Mar 16, 2010
    #7
  8. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    Used Din-rail 5500PCU and 5500PC (took one from another site), both firmware 4.6.00.
    I'm not intercepting them, really, just defined CBUS_DEBUG_MODE in linux_cbus.c so it echoes all the characters from receive and send queues to stdout.
    Yes, MMI come in fine, but since module is stuck in this loop, it does not process them.
    It is received, but not processed.
    In cbus.c, function cbus_ef_update: when ping fails, it sets e_update_state=cbus_ce_module_ping_fail. This way cbus_ef_update() gets stuck, because with this e_update_state all it does is return e_update_state every time it's called. I changed the code:
    Code:
    switch e_update_state
    {...
        case cbus_ce_module_ping_fail: 
            vf_send_immediate_cmd("~~~\r");
            e_update_state=cbus_ce_module_not_initialised;
            return e_update_state;
    ...}
    So now it's closing and reopening connection, if ping fails, but it takes a while and happens way too often.
    Now it can keep up forever (I hope), but sudden reconnects may cause problems. So not sure it's the best way.
    Tested with C-Touch and COM PCI, same effect.
    Sounds like there's something wrong with kernels I'm using, though it's strange.
     
    AlexeyR, Mar 16, 2010
    #8
  9. AlexeyR

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,363
    Likes Received:
    10
    Location:
    Adelaide, South Australia
    There is something wrong with the USB driver and/or kernel on your system.

    There should be no need to close and re-open the connection to the serial port. The code has been running, with no modifications from how it is in sourceforge, for several years. The original testing and development was done on Fedora Core 1 (thats how long ago it was).

    It also runs OK on some special (custom) builds of Linux, and others have had it running on Ubuntu and one other that I can't remember now. In all cases, though, it was with a direct connection to a genuine serial port.
     
    ashleigh, Mar 16, 2010
    #9
  10. AlexeyR

    grw001

    Joined:
    Dec 6, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Sydney
    Just wondering whether this problem with the 5500PCU and accessing it via Linux was looked at further?

    Glenn
     
    grw001, Feb 7, 2011
    #10
  11. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    Are you getting it too?

    I'm afraid I have another connected issue, if not the same ? on another site we have a connection CBus to LON via Xenta 913. It's an older project and we've been having a problem with this Xenta module, it kept hanging after random periods forcing us to reset it, so in the end we had to simply disconnect those networks and let them work separately. It might be or might not be connected, but symptoms are very similar.

    After over a year of experimentation I still can not find the source of this problem. Right now I've modified cbm code to re-ping 5 times before sending signal ping_failed into connect handler and let my program decide. This way it stays connected (though once I had a rain of failed pings, had to reboot PCI) and works better, but during such re-pings it can not receive any the other messages from CBus network thus loosing some of them and causing glitches like partially switched scenes that depend on systems other then CBus. And that's what we need laptop for ? to switch on devices that can not be connected to CBus.

    As I said before, only "voltage requests" arrive without first bites only, all other messages come in fine even after "cut" voltage with my modifications. It's definitely not kernel or USB-to-COM driver or even notebook hardware, I've tested many kernels and systems, several notebooks and direct RS232 connection, results were identical.
    More then that, Toolkit and PICED running on windows are acting strangely with those same PC interfaces (on this project and one with Xenta), simply connecting to network sometimes takes up to 10-20 minutes, while on older bigger networks it took much less time to connect and scan the network. They do hang sometimes, but in this case I can't tell if it has something to do with "voltage pings", Cgate log does not show any anomalies.

    One thing I was not able to test is different PCI firmware. If you say it's been working fine long ago, then older versions of PCI might not have this issue. Unfortunately, we have no modules with older firmware, so nothing to test this assumption on.

    I can't post my patch to cbm right now, it's on my other computer.
     
    AlexeyR, Mar 20, 2011
    #11
  12. AlexeyR

    Darren Senior Member

    Joined:
    Jul 29, 2004
    Messages:
    2,361
    Likes Received:
    0
    Location:
    Adelaide, South Australia
    We have been discussing the problem you have had, but we are unable to determine a likely cause.

    Are you able to clarify a few things for us?

    I understand that this problem occurs for you with:
    1. Different computers
    2. Different operating systems (all Linux variants)
    3. USB PCI and Serial (RS232) PCI
    4. Using the C-Bus Module code from Source Forge with no changes at all

    Is this correct? If I have not described the situation exactly right, please let me know.

    Can you provide the version number of your Linux USB driver?

    See http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx for the latest drivers.

    Did you definitely see these bytes missing from the reply messages when using the RS232 PCI, or was it just with the USB PCI?
     
    Darren, Mar 21, 2011
    #12
  13. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    Yes, it occurs on different computers running Debian Squeeze and Ubuntu 10.04, connected to USB and RS232 PCI with firmware 4.4.00 using cbm from sourceforge with no modifications. It simply hangs after a while not processing commands.
    Right now computer (Debian Squeeze with linux kernel 2.6.32-5-amd64 without any modifications) is connected to RS232 PCI, here's how it looks if LINUX_CBUS_DEBUG is defined during cbm compilation on example provided with cbm source code:
    Code:
    Initialising...
    Registering event handlers
    Opening /dev/ttyS0
    Opened...
    ~~~
    ~~~
    2102
    2102
    8902342E342E3030202011
    
    1AF304
    1AF304
    85F31876A2BB9D
    
    1A2001
    1A2001
    82200955
    
    2107
    2107
    860732392E35564F
    
    1A3E01
    1A3E01
    823E013F
    
    A32100FF
    A32100FF
    322100AD
    
    A342000F
    A342000F
    3242008C
    
    1141
    1141
    8241D766
    
    A3410079
    A3410079
    3241008D
    
    A3300079
    A3300079
    8609090032300006
    
    C-Bus is connected
    PCI Unit Address   = 9
    PCI F/ware version = 4.4.00  
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    @2107D8h
    h.86090900860732392E3756B5
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    \05DF00110308i
    i.86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    @2107D8j
    j.86090900860732392E3756B5
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    \05DF000E0207DB0316010D0109371F00A3k
    k.86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    @2107D8l
    l.86090900860732392E3556B7
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    @2107D8m
    m.86090900860732392E3756B5
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    @2107D8g
    g.86090900860732392E3756B5
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    050C38001A690C1A6AFFA5
    
    CBus event: app=56, group=105, level=12, rate=3
    CBus event: app=56, group=106, level=255, rate=3
    86080900F74038B000000000000000000000000000000000000000004A
    
    @2107D8h
    h.86090900860732392E3756B5
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    050C38001A6A0C1A68FFA6
    
    CBus event: app=56, group=106, level=12, rate=3
    CBus event: app=56, group=104, level=255, rate=3
    @2107D8i
    i.86090900860732392E3556B7
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    86080900F940380000000000000000000000000000000000000000004A
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    050C38001A680C1A69FFA7
    
    CBus event: app=56, group=104, level=12, rate=3
    CBus event: app=56, group=105, level=255, rate=3
    @2107D8j
    090900860732392E3556B7
    
    86080900F74038B000000000000000000000000000000000000000004A
    
    86080900F74038B000000000000000000000000000000000000000004A
    After this everything keeps going in, but not processed and it does not send any more @2107D8.

    One more thing I noticed is that if there's another computer connected to CBus network via any other PCI, this failed ping occurs much faster.

    Checksums on those headless ping replies look like they've been calculated from a full and correct reply, so I conclude PCI gives a correct answer, meaning it's head get lost somewhere between PCI send queue and cbm receive queue.
     
    Last edited by a moderator: Mar 22, 2011
    AlexeyR, Mar 22, 2011
    #13
  14. AlexeyR

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,363
    Likes Received:
    10
    Location:
    Adelaide, South Australia
    3 tests needed here for comparison:

    1. Does it run OK on windows?
    ANS: Yes, and has done for many years.

    2. Does i t run OK on linux using a real hardware serial port?
    ANS: Yes, last I checked it was OK (and several portings to other linux platforms have been OK)

    3. Does it run OK on embedded processors?
    ANS: Yes, on at least 6 I can think of w/o trying very hard.

    All this leads me to believe that it is a USB driver problem with the USB/Serial converter and the virtual COM port.
     
    ashleigh, Mar 22, 2011
    #14
  15. AlexeyR

    Darren Senior Member

    Joined:
    Jul 29, 2004
    Messages:
    2,361
    Likes Received:
    0
    Location:
    Adelaide, South Australia
    One really important thing we need to know is whether the RS232 PCI is connected to an RS232 port on your computer, or if it is connected to a USB port via an adaptor.

    As Ashleigh has said, we have never had any problems with any devices using the C-Bus Module with a serial (RS232) PCI, and there are currently tens of thousands of devices out there using this set-up (mostly embedded devices using an in-built serial PCI).
     
    Darren, Mar 22, 2011
    #15
  16. AlexeyR

    AlexeyR

    Joined:
    Mar 12, 2010
    Messages:
    7
    Likes Received:
    0
    Location:
    Russia
    Didn't I say that? Yes, it's connected to a hardware honest to Emperor serial port on laptop. RS232 to RS232, COM to COM, serial to serial. With a cable that came with PCI. No USB now, whatsoever. This log I've posted was taken with RS232 connection (/dev/ttyS0). It's not a usb problem anymore.

    So it does not run OK on linux using real hardware serial port for me.
    Ashleigh, what system do you run with what kernel version? I may be able to install it and see if it anything changes, so far I've only tested on Debian based systems.

    I have no embedded systems handy, so can't test that. But I'll test it in windows as soon as I can.

    And one more thing, is there any way to connect cbus module to CNI module?
     
    AlexeyR, Mar 23, 2011
    #16
  17. AlexeyR

    ashleigh Moderator

    Joined:
    Aug 4, 2004
    Messages:
    2,363
    Likes Received:
    10
    Location:
    Adelaide, South Australia
    I tested it on Fedora Core 1 (a long time ago).

    It has also run on a number of ARM based linux systems - again this was a long time ago.

    It may be that the serial port driver is losing characters if they are not picked out of the receive buffer in time, though at 9600 bits/sec this would be a heck of a surprise on a modern OS.

    The method used on linux of delivering regular timer ticks may also be something to consider - this is wrapper code around the cbus module and something I was never super-happy with. It should be OK, the OS should happily deliver the ticks but its not something I have seen elsewhere as a "this is a good way to do this" method. If it is, then fine. If not... perhaps there is a better way.

    As for communicating with a CNI - you will need to write your own code for this, you just need to open a socket connection (TCP, not UDP). For writes I suggest your try and accumulate a few characters before writing, this will reduce the overheads (40-odd bytes of TCP header to send 1 byte of data just offends me). For reads the CNI will tend to batch up a few characters so when you do a socket read you may get some number of characters at a time (1.. something possibly large, such as 80-100 characters). Then poke those into the cbus module 1 character at a time. You will still need the regular timer ticks.
     
    ashleigh, Mar 23, 2011
    #17
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.