Open nomis52 opened 9 years ago
I keep getting stuck in
Changed to 10
Which is STATE_C_RX_WAIT_FOR_DUB
. It seems that it never times out...
The device is also not responsive anymore via USB, it is completely frozen...
I am using the reference design: https://docs.openlighting.org/ole/doc/latest/reference-design.html
Anyone using that as well?
Are the defines of app_settings.h
still correct for ethernet_sk2? Especially the IC define?
https://github.com/OpenLightingProject/ja-rule/blob/master/boardcfg/ethernet_sk2/app_settings.h#L73
It happens when I start olad
, which triggers a RDM discovery.
If I disconnect my fixture, it is fine.
The transceiver self-check passes. (But it does not use the same timers/IC).
Anyone can help me out? @nomis52 @peternewman ?
@peternewman : Do you have the OLA RDM test suite still running?
Is there any Ja-Rule board we can order somehow, alternatively, if the reference design is not supported?
@peternewman : Do you have the OLA RDM test suite still running?
Yeah, I ran some through a Number 1 at the recent Lille Plugfest seemingly without issues (aside from with the device under test). Is that what you meant?
Is there any Ja-Rule board we can order somehow, alternatively, if the reference design is not supported?
The company that made the original batch of Number 1's aren't doing so anymore unfortunately. The design is here, but I'm not sure if it includes a PCB layout: https://github.com/OpenLightingProject/ja-rule/tree/master/hardware/number1
@peternewman , thanks for your reply. We've met actually in Lille ;-), I was the one of Constell8/KLSTR.
The hardware schematics are there of the Number1. But we bought the development kit of Microchip, which the Number1 was based upon. But can't get it working with that...
One thing I found during testing today, if you disconnect the IC line, the unit 'locks up' when used as an RDM controller with one or more responders on the line. This is because without IC we never enter the STATE_C_RX_IN_DUB but the UART is still receiving and Transceiver_UARTEvent() is called repeatably.
This is symptomatic of a general class of 'abnormal' failures. If something happens that we don't expect, we should enter the ERROR state and reset the unit.
e.g.
That last line should handle the failure.