Reef Angel Forum

12 bit resolution is in the dev libraries and working great. You now get full 8 bit resolution on the built-in ports and 12 bit on the current dimming modules. Some older ones may still he 8 bit. PM Roberto (rimai) to purchase a 16channel module.

Could someone post a guide on how to work the 12 bit dimming?

Thanks,

--Colin

If your using InternalMemory you don't have to do anything. If your setting them manually with the parabola or slope functuons you can just add HighRes to the function name.

For set and get functions, just add Raw at the end.

How does that work with the standard PWM ports? Still use PWMSlopeHighRes? How will it know the difference between, say, 50% and 50?

I guess the Portal and the RA Status app still use bytes to store the values for the PWM Expansion module? They're rolling over every 255.

Thanks,

--Colin

Yes GetValue() and the portal will get the byte value. But if you want to write a high res number then you'd use SetDaylightRaw(). Then when it writes it will scale it down to 0-255. The HighRes functions all output 0-4095 (12 bit range)

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

Thats pretty damn good. All drivers need some amount of voltage in order to get going. The LDDs are low for sure. 21 is like .005v

Yeah, I think that is the minimum that your driver will take, which is pretty good in my opinion.
How does the LED look at 21?

A little too bright for a moonlight, but I have 40 LED's on that channel.

--Colin

Cool. I've never driven mine down that low on purpose, but I should try with some Raw commands. I know I used to do a slope from 0% to 3% over 3 hours using HiRes functions and it was really really dim at first. I don't know what the raw value was, though.

I owe Roberto a users guide to how the new dimming stuff works and how you'd access it if you wanted to get to it from the .ino file.

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.