Problem with CBus Module through USB

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.

 

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?

 

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.

 

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.

 

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

 

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.

 

Just wondering whether this problem with the 5500PCU and accessing it via Linux was looked at further?

Glenn

 

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.

 

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?

 

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.

 

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).

 

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?