Understanding high-density channel data for streaming via UDP


I am trying to understand how to interrupt the high-density channel data located in the OPTOMMP starting at address FFFF F100 0300. According to the structure on page 155 of the manual, this section should have the analog channels value in engineering units and the feature data for digital channels.

For now, I am trying to read the state of a digital output from a GRV-ODCI-12 card located in slot 0. The controller is a GRV-EPIC-PR1. From looking at the Generic MMP using groov Manage, I never see data change in the first 2048 bytes of data that should be in address FFFF F100 0300 to FFFF F100 0AFF. I tried toggling the digital output state via Groov Manage and no changes were seen in this data. Also checked when streaming via UDP and detected no change in this area of data.

I do see the values change starting at FFF F100 0B02 and 03, which lines up with what the guide states starts at that memory location for digital channel state.

How do I read this data in the first section of 2048 bytes, or is this just not possible? Also how does the first 2048 bytes map to the given module and channel in the module?


Hello Adam, welcome to the forums!

That area of memory is specifically for streaming data, it’s different from the standard channel read areas and does have to be configured separately.

Here’s the section on configuring the parameters to stream from page 86, can you double check that and let us know if it gets you up and running?

1 Like

Hi torchard,

Sorry for the delay, had notifications turned off. I do have streaming enabled and am receiving data via UDP. I have validated as well that changing the millisecond time changes the frequency of data being received. However I do not see any values change in the first 2048 bytes of data sent, there are a total of 2304 bytes being sent per packet. I do see the digital output states change value in the data starting at at address FFFF1000B00, offset of 2054 bytes (for channels 8-11) and offset of 2055 bytes (for channels 0-7).


Is there other data you are not getting besides these digital states? For example do you need to stream feature data as well?

As of right now, no as I only have a single card connected. But trying to understand why the digital states aren’t in the first section of data as specified in the manual, or what I am doing wrong to configure the data to be in that section as well.

That first section of data for digital channels is only for feature data, like counters.
If you do not have any features set up for that point you will not see any changes there, only in the F100 0B00→ area where the state is, which you have already found.

Can you test this out by setting up a counter for one of the points, toggle it a few times, and check it again?

EDIT: Note that simple modules do not support features like totalization etc, so it will not work for every module, only those with features both supported and enabled

1 Like

Looking at page 43-44 of the OptoMMP Protocol manual, and it shows that the State is part of the feature data for digital channels. Should this not be included as part of the data in the first section? Or I am misreading what the manual is stating. If I am misreading that, and the state data is only in the 2nd half of the stream, that is fine for my application, but tying to better understand the data streams from Groov Epic controllers.

I can see how that can be confusing - the “feature” that is in the streaming area is specific to the configurable digital feature - not the automatic features (state and latching). The default for the configured feature is 0, which is disabled.

Here is the table of possible digital feature values, when this is set and the module supports it, the result will show up in the first 2048 bytes of the default streaming area.

If you are only looking for specific streaming data, then you may want to consider setting up custom streaming to stream only the data you want.


Thanks for the explanation! I was confused on reading the manual with what was included there. Standard streaming is working out well so far, but just wanted to make sure I fully understood the specification before further development.

1 Like