Reef Angel Forum

cosmith71 wrote:Disregard the second half of my previous statement. I was doing it wrong.

Got it running, but I've noticed I can't dim below a raw value of 21 with my LDD drivers. At 20 they shut off. Hardware limitation or software issue?

--Colin

OK, so I've figured out that this really isn't a raw value of 21. I'm using the RANet dimming module which works off of an 8 bit value scaled up to 12 bits (multiplied by 40.95). So 21 is probably the break point between 0 and 1%.

What I'd like to do is use the bytes in the RANet packet normally used for the 16 channel dimmer for some sweet 12 bit dimming action.

What would be the best way, with a 6 channel dimming module defined, to send along some 16 channel data? I think plucking it out on the RANet receiver side would be easy enough. From what I've seen, you can have a 6 or a 16, but not both.

Maybe just define as a 16 channel and re-write the receiver code to translate to 6 channels?

--Colin

Damn... You are digging it deep huh? I like it.
I doubt this is the case.
21 in the RANet packet is really 21%.
Just to make sure we are talking about the same number, go to your dimming channels in your RA and look at the % for that channel.
Is it 21% or 1%?

It's 1%. But I'm writing a raw value of 21, which I'm guessing is converted to 1%, sent to the RANet receiver, which then converts it to 1*40.95 and sends it on to the dimming module, right? So my end result is a raw value of 40.

--Colin

Yeap. You are correct then.
I think the only way we will be able to achieve this is to make the RANet payload bigger and send int values instead of byte values.
Can you open an issue in the github?

Done.

Isn't an int 4 bytes? We only really need 2 (or even 1.5). Not sure how big the payload can be.

--Colin

int is 2 bytes

Doh! I misread. Of course it is.

I did a little work on this, and got GitHub working.

Something is still wrong. I changed the payload to 68 bytes to accommodate 2 bytes for each expansion dimming and 16 channel expansion dimming and changed the RANet receiver software to read it. None of the channels are working as expected and I'm not really sure how to debug it.

My repositories are cosmith71/Libraries and cosmith71/RANet-Reciever. Not sure if that is what you need to find them?

Thanks,

--Colin

I'll take a look at it.

Thanks. Made a couple of changes this morning, but still not correct. I'm wondering if I have my MSB's and LSB's reversed some how.

--Colin

OK, got it fixed! I now have full 12 bit dimming on my RANet 6 channel dimming expansion!

Not sure what happened. I spotted an error in the receiver code that I swear I fixed earlier. Changed that and it's working.

I used a spare Xbee and the USB module I bought to program them to intercept the data stream. I used a program called RealTerm to look at the hex stream the module was receiving and made sure the 16 bit payload was being sent correctly. It was. That led me back to the receiver code. Turns out I had an error in the code that selects the channel I'm loading. Once that was fixed, it worked!

So now the RANet payload consists 8 bytes for relay boxes, 8 bytes for fallback relay values, 12 bytes for 6 channel dimming (2 bytes per channel) and 32 bytes for 16 channel dimming (not yet implemented, but would be same as 6 channel).

Now, I just need to implement lightning and clouds. It'll take an adjustment to the trigger mechanism.

--Colin

Awesome!!!
While you are at it and hand on , add the trigger to the payload.
If we add a new byte to the payload, we can trigger up to 255 commands.
So, 0 would be no commands, 1 would be lightning, 2 would be something else and so on.
Then, all the receiver needs to do is check for that byte and trigger it accordingly.

Great idea! I was just going to hide it in the high 4 bits of one of the channels, but I like the idea of a dedicated byte better. Time to put my thinking cap back on.

--Colin

OK, so that's done. I just added a byte onto the packet at the end right before the terminal <CR><LF>.

Now my problem is I don't know how to set it. I guess we need a new library function? Something like ReefAngel.SetRANetTrigger(trigger value)?

--Colin

That should work

Done. ReefAngel.RANetTrigger(byte) is now a thing. RANet Receiver with Lightning code updated as well.

--Colin

Holy cow! Way to go colin!!!

Yes, certainly my crowning achievement as a coder.

Roberto, should I submit pull requests? It won't work on a RANet dimmer without updated code.

--Colin

Yes, send me a pull request and also the updated firmware for the receiver.

Done.

I had a thought. We could use different trigger values to trigger lightning on different channels. Say, 1 flashes channel 1, 2 flashes 2, 3 flashes 1 and 2, something like that.

Maybe even make the trigger an int to open up possibilities.

--Colin

You can have 256 possibilities with a byte... just sayin

I know. I'm just thinking out loud.