Jump to content

ImageCue


maeterlinck

Recommended Posts

Hello Blueroom Hive Brain!

 

Firstly - I've already emailed the manufacturer, but I thought worth also posting to see if anyone had similar experiece or any advise or suggestions. (Some below is cut and pasted from my email to ImageCue).

 

We purchased an ImageCue (http://imagecue.lighting/). It's a device that acts as a simple mini media server - ideal for placing next to a projector or screen and triggering content via DMX. Fairly simple device based on a RaspberryPi with a custom DMX control card by ImageCue.

 

It's labeled as being compliant with both ANSI E1.11–2008 ANSI Standard E1.20-2010, so all should be good. Over a wired connection with have no issues. One ImageCue needed to be located on a Wireless DMX link and this one has issues. We ruled out the usual contenders for 'wireless issues' - so hopefully can skip those.

 

We have been working on this in the workshop in a controlled environment with little radio interference (the benefits of being based in the countryside!). We have proved the wireless connection with other devices and DMX testers.

 

The wireless DMX link is made using City Theatrical ShowDMX kit. This reclocks the DMX line and varies the refresh rate of DMX packets based on the incoming radio signal or packets. At the higher speed the refresh rate is similar to that of the DMX source (say 40Hz in this case), but every 10 seconds or so (it varies) the refresh rate will drop to ~23Hz.

 

This shows on the ImageCue as a flash on the screen thinking it has received an RDM packet. This causes the video to stutter and restart. We can create this by sending actual RDM traffic to the network and the ImageCue will respond. We have tried with RDM disabled and enabled on the wireless link the the behaviour is the same with the ImageCue. On a wired connection there is no issue with no RDM traffic being sent.

 

I believe it is acceptable behaviour for a DMX master (source) to vary the refresh rate on the fly, and other devices we have are able to listen to this happily - as well as the devices we make in house. I think there is an issue with how the ImageCue deals with the Break and MAB (Mark After Break), as this would be the aspect that the City Theatrical device would likely be varying to alter the refresh rate. I haven't yet verified this with an oscilloscope or logic analyser but is the most likely cause.

 

--------

 

So that's the problem.

 

Has anyone had something similar?

Any input on the CTI wireless changing the refresh rate? I've not had an issue with this before so not needed to look in to it further.

Is there a work around on the CTI gear to stop the DMX rate changing? (I've not spoken to City yet - but that might be the next port of call).

Any other suggestions!?

 

Assuming my diagnosis is correct I have asked ImageCue to either fix what I think is a bug in their DMX reception code (the ideal solution) or to stop the video restarting on RDM reception (which would be an acceptable workaround.

 

Thanks in advance for any help!

Link to comment
Share on other sites

Where are you based? Would it help to try a different wireless link?

Thanks! We have several available. It is almost certianly what the CTI wireless link is doing to the DMX (i.e. basically reclocking it and then changing the speed periodically). On this job we're committed to CTI otherwise I would use Wireles Solutions and set the mode to match the incoming DMX rate.

Link to comment
Share on other sites

Where are you based? Would it help to try a different wireless link?

Thanks! We have several available. It is almost certianly what the CTI wireless link is doing to the DMX (i.e. basically reclocking it and then changing the speed periodically). On this job we're committed to CTI otherwise I would use Wireles Solutions and set the mode to match the incoming DMX rate.

 

No probs - I have access to an RC4 that could have been brought over for a quick test, but I guess you're on top of it already.

Link to comment
Share on other sites

Would it help any to put a DMX splitter in between the wireless receiver and the ImageCue? Not sure if the right unit would pass steady DMX or follow the rate fluctuations from source.

A 'passive' splitter wouldn't help as DMX In = DMX out. However, an RDM buffer, or maybe a merging one would - as it would genuinely buffer the data. It's a big hammer for the problem though. I also don't have one to hand to try...

Link to comment
Share on other sites

What precise ShowDMX kit are you using?

SHoW DMX NEO TRANSCEIVER

5701M

 

QolorFLEX® SHoW DMX Neo® 4x2.5A Dimmer

5742M

Ok and are you certain that you disabled RDM traffic (on the front panel of the 5701)?

Link to comment
Share on other sites

Ok and are you certain that you disabled RDM traffic (on the front panel of the 5701)?

 

We have tried with RDM disabled and enabled on the wireless link the the behaviour is the same with the ImageCue.

 

Very much so.

 

As an aside on RDM in CTI kit - we noted somewhere in a manual it talks about disabling RDM on the recieving device. Slightly ironically this is only achievable via RDM. It's not one of the IDs that our Swisson understands.

 

But doesn't quite sound right as the reciever should be an RDM responder and forwarder, i.e. it should only send RDM traffic when it recieves RDM traffic.

Link to comment
Share on other sites

Ok and are you certain that you disabled RDM traffic (on the front panel of the 5701)?

 

We have tried with RDM disabled and enabled on the wireless link the the behaviour is the same with the ImageCue.

 

Very much so.

 

As an aside on RDM in CTI kit - we noted somewhere in a manual it talks about disabling RDM on the recieving device. Slightly ironically this is only achievable via RDM. It's not one of the IDs that our Swisson understands.

 

But doesn't quite sound right as the reciever should be an RDM responder and forwarder, i.e. it should only send RDM traffic when it recieves RDM traffic.

RDM over wireless is only possible at all by making the receiver do a lot of the hard work.

 

The wireless link receiver must do the Discovery and let the TX end know "who exists", so the transmitter end is able to let the controller know.

Otherwise it'd be impossible for RDM Discovery to work across a wireless link because there isn't enough time.

 

So the receiver is sending out RDM packets on its own, in order to be able to start doing RDM if and when the controller asks for it.

 

- In technical terms, all wireless RDM systems are active "RDM Proxies" as described in E1.20.

 

So to disable RDM, it has to be disabled in the receiver. There isn't yet a standard PID for this, so every wireless RDM system has to use its own.

 

(There is a standard one currently being proposed in an E1.37-?, which is also intended for configuring RDM splitter ports and E1.33 to RDM Nodes/Gateways.)

Link to comment
Share on other sites

Ok and are you certain that you disabled RDM traffic (on the front panel of the 5701)?

 

We have tried with RDM disabled and enabled on the wireless link the the behaviour is the same with the ImageCue.

 

Very much so.

 

As an aside on RDM in CTI kit - we noted somewhere in a manual it talks about disabling RDM on the recieving device. Slightly ironically this is only achievable via RDM. It's not one of the IDs that our Swisson understands.

 

But doesn't quite sound right as the reciever should be an RDM responder and forwarder, i.e. it should only send RDM traffic when it recieves RDM traffic.

RDM over wireless is only possible at all by making the receiver do a lot of the hard work.

 

The wireless link receiver must do the Discovery and let the TX end know "who exists", so the transmitter end is able to let the controller know.

Otherwise it'd be impossible for RDM Discovery to work across a wireless link because there isn't enough time.

 

So the receiver is sending out RDM packets on its own, in order to be able to start doing RDM if and when the controller asks for it.

 

- In technical terms, all wireless RDM systems are active "RDM Proxies" as described in E1.20.

 

So to disable RDM, it has to be disabled in the receiver. There isn't yet a standard PID for this, so every wireless RDM system has to use its own.

 

(There is a standard one currently being proposed in an E1.37-?, which is also intended for configuring RDM splitter ports and E1.33 to RDM Nodes/Gateways.)

 

 

If you send a 0x00 to PID 800A it does indeed disable the RDM packets coming out of the 5742. Just tried it with a scope connected. That's to the 5742 of course, not the 5701

 

Dave

 

 

 

Link to comment
Share on other sites

If you send a 0x00 to PID 800A it does indeed disable the RDM packets coming out of the 5742. Just tried it with a scope connected. That's to the 5742 of course, not the 5701

 

Dave

That's the one. 0x01 to enable, 0x00 to disable.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.