setBreak/clearBreak for manual break control

[ettavolt]

Could you please update dynamic libraries so that it is possible to use this library for DMX? It requires microsecond precision. Even 1/10th of a millisecond (1e-4 s) would be OK.

[RishiGupta12]

I have seen the link. I need to understand your requirement more. Please share

• how exactly you will use the library
• where exactly precise timing will be needed
• which hardware you will use

[ettavolt]

1. Either startBreak() and endBreak() methods (so that I can do timing the way I want) or sendBreak(micros), where micros is the break duration. It may be a good idea to implement as sendBreak(millis, nanos), just like Thread#sleep(millis, nanos) does.
2. It is actually needed only for sending break. I can implement mark-after-break with Thread#sleep(millis, nanos) on Java side. The SCM library already supports 250kb/s speed, so no problem here.
3. I'm using CP2101-based USB-to-RS-485 converter. Actually I was able to control device sending a 1ms long break (thanks to standard, it doesn't constraint the max duration).

So, without such precise method I'm simply wasting 900 microseconds (~225 bits / ~28 packets). :)

[RishiGupta12]

Break duration is dependent upon operating system + driver + hardware. Which OS you are using.

[ettavolt]

I'd like to have it working on Linux/Windows. Could you please describe the dependency in more detail? Do you mean, that it is not possible to implement break with such granularity?

[RishiGupta12]

Time taken by hardware to set/unset break can not be changed. Time taken by driver + OS + application is dependent upon your hardware/system configuration. Time taken by application can be reduced if we use C instead of Java upto certain extent. Is that 900uS really affecting your use case.

[ettavolt]

Windows has SetCommBreak/ClearCommBreak. Linux has TIOCSBRK/TIOCCBRK commands for int ioctl(int fd, int cmd, ...); function. I bet OS X has same API.

So, instead of increased granularity of the duration parameter I can benefit from setBreak/clearBreak methods. Of course, it won't a become a huge improvement, at least for me.

[RishiGupta12]

SCM also uses the functions you mentioned. But the time spent in Java/JNI layer can not be optimised after certain extent. Why you need that much granularity.

[ettavolt]

Just a need for speed, you know. :) I think the less the break I can send, the smoother the control will be. So, if it is not very hard, could you please exposes such functions in Java API?

[RishiGupta12]

Take a look at http://lxr.free-electrons.com/source/drivers/tty/tty_io.c#L2714

Duration also depends upon OS granularity. Exposing in java means more overhead and more delay. SCM internally manages the subtle OS specific timings and other complexities etc.

[ettavolt]

Well, according to some tests Java → setBreak/clearBreak → Java round trip won't take more then a microsecond on general-purpose 2GHz+ processor. So, if setBreak/clearBreak (not sendBreak(micros)) get exposed to Java, developers could implement microsecond precision themselves.

[RishiGupta12]

How did you measured 1 ms break (cp2101). Also at the receiver side (light module) which hardware you are using.

[ettavolt]

Well, I've just used sendBreak(1). :) Don't now what's in receiver, it has controller embedded. Anyway, I don't think its model is relevant, because we have a very specific DMX-512 standard.

[RishiGupta12]

• Use latest jar from here for need for speed: https://github.com/RishiGupta12/serial-communication-manager/tree/master/prebuilt-release API call (note 0): scm.sendBreak(handle, 0);
• Thread#sleep(millis, nanos) does not provide sleep in nanoseconds. It is a hint to scheduler not guarantee.
• DMX512 is standard but receiver hardware may not be able to detect short break which will then manifest itself as framing error. Please consult your hardware manual.
• Round trip time is not constant but depends upon many factors. If you use bench-marking you will observe surprising results. I have seen 3ms round trip time many times even for stress test.

[ettavolt]

Just read new JavaDoc on SerialComManager#sendBreak. Looks like there is a lot of obstacles for sending short breaks. Now I think that more or less stable 1ms is much better for my case. Though I do understand, that depending on hardware it may be more then 1ms actually. One nice feature of DMX-512 is that it doesn't specify maximum valid break time. So one can send quite long breaks. And receivers should consume as much frame errors, as there will be.

Thank you very much for discussion.