Resolution of RF Vortech command

[rimai]

I don't have any plans to change the original firmware.
I'll build one for you or anyone that wishes better resolution.
The long pulse of the ecotech driver does a couple hours too. It's for those that implement gyres.
Now that you pointed out, I went to the ecotech manual and it says the short pulse goes from .2 to 2 seconds.
Their knob has 8bit resolution too. So, it means the driver has a resolution of 7ms.
I can make a custom firmware with whatever value you prefer.
What would you like to have?

[dedvalson]

Hi,

I think the 7mS original sounds good. I really appreciate your amazing support.

Would it be worth adding another command to the firmware to set this so that you don't have to keep making custom things?

Don

[rimai]

Now I wonder what they meant with the 2 second pulse. Is it 1/2 cycle or full cycle?

[dedvalson]

I can test that tonight if you would like me to.

I guess to test that I would need to reset my Vortech and then do the test. After that I would have to put different firmware in my RA to connect to the Vortech, reset the Vortech, reconnect the Vortech, then put my sketch back into the RA. Is that correct?

Maybe in a future version of the RA code we could add a "connect" mode to the operating code so that it isn't necessary to upload different sketches.

Don

[lnevo]

I am interested in this... I think

It sounds like it would give better resolution on the durations... What would be the downside?

[dedvalson]

Roberto,

I tested the short pulse and long pulse on my MP40W running in stand alone.

The results I found were:

Short Pulse:

Fastest Speed: 0.6 seconds per full cycle (0.3 on 0.3 off)
Slowest Speed: 4 seconds per full cycle

If you set a step to 8 mSec (8 mSec on, 8 mSec off) this would give a slowest speed of 4.08 seconds. This would mean that 37 would correspond to their fastest speed.

Long Pulse:

Fastest Speed: 4 seconds per full cycle
Slowest Speed: 120 seconds per full cycle

If you set a step to 250 mSec (250 mSec on 250 mSec off) then 255 would be 127 seconds. 8 would be 4 seconds.

So it appears that 8 mSec is the closest to what they do in short pulse and 250 in long pulse.

Thanks,

Don

[dedvalson]

Actually it looks like my Slow Pulse measurements were off. It will go a lot slower than I said. I didn't actually have it turned all the way up. When I did it went about 12 minutes on and 12 minutes off.
Don

[rimai]

Follow the same instructions in here:
http://forum.reefangel.com/viewtopic.php?p=13002#p13002

[rimai]

Forgot to add....
I created 3 new modes instead of changing current ones.
Mode 12: Slow Pulse with 8ms resolution
Mode 13: Long Pulse with 250ms resolution
Mode 14: NTM with 8ms resolution

[dedvalson]

Awesome, Thanks.

It may take may a day or two before I can try it out.

THanks,

Don

[dedvalson]

Hi,

I finally got time to put the new firmware in the RF Module. I ran into several issues with it.

1. In Mode 12 (short pulse) the pulse speed isn't consistent. It seems to pulse 3-4 times at the correct speed and then hesitate and them 3-4 again.
2. Mode 14 doesn't seem to work at all. It will work for a few cycles and then "get stuck". When I power the RA down and up again it will run for a few cycles again and then stick.
3. After uploading the RF module, I now have trouble uploading to the RA. The upload appears to work, but then it reads back a ton of data (takes several minutes) and then says the data doesn't match the upload. The upload seems to work fine. I tried re-installing the RA software but it didn't make any difference. Some setting must have been changed.

Thanks,

Don

[rimai]

I don't think #3 is related.
Can you restore the RF back to original firmware?

[rimai]

Ok, so I went and sniffed the driver to confirm.
The driver cannot do any less than 60ms resolution.
It broadcasts data every 60ms.
So, let's take the short pulse as an example...
With 12 bubbles, it takes the driver 21 broadcasts to invert from 0% to 100% and another 21 broadcasts to invert back from 100% to 0%, making a total of 42 broadcasts, which is equal to 2.52s
With 1 bubble, it takes 4 broadcasts each for a total of 8, which gives 0.48s
0.24s is the minimum you can have each half of the cycle.
It explains why it is skipping cycles.... We were trying to send data too fast and overshooting ourselves.

[dedvalson]

I don't think #3 is related.
Can you restore the RF back to original firmware?

I don't think this is related to the RF firmware at all. I think some setting got changed when I unzipped the software to update the RF firmware. Is there a file that tells how to manage the upload? I think it is trying to do a verification of the uploaded code that it didn't used to do.

I just wondered where that setting might be so I can fix it.

Don

[dedvalson]

Ok, so I went and sniffed the driver to confirm.
The driver cannot do any less than 60ms resolution.
It broadcasts data every 60ms.
So, let's take the short pulse as an example...
With 12 bubbles, it takes the driver 21 broadcasts to invert from 0% to 100% and another 21 broadcasts to invert back from 100% to 0%, making a total of 42 broadcasts, which is equal to 2.52s
With 1 bubble, it takes 4 broadcasts each for a total of 8, which gives 0.48s
0.24s is the minimum you can have each half of the cycle.
It explains why it is skipping cycles.... We were trying to send data too fast and overshooting ourselves.

Hi,

I assume that a "bubble" in this case means intermediate speeds that are sent out, so that the speed is ramped up and then back down instead of "on" and "Off". Is that correct?

Is the 60ms number a characteristic of the Ecotech RF environment or the RA RF Module firmware? It seems like that when one Vortech controls the othe Vortech the available resolution is very high. The steps from one speed to another are imperceptable and that allows me to tune the speed to cause standing waves in the system.

I am guessing that what the Vortech must do is that it goes ahead and uses a smaller number of "bubbles" but varies the timing of them. For instance, if it takes 60 mSec to send a command, you can send a command every 60 mSec or every 65 mSec or every 70 mSec, giving you 5 mSec resolution. I think that they must be varying the "dead" time between the commands.

I am quite familiar with low level firmware of this nature and would be glad to help work on this if you would like.

Don

[rimai]

The bubble I mentioned is the led lights in the driver.
There are 12 leds for that goes up as you increment the duration.
The 60ms is default and does not change. It only sends every 60ms, no matter which duration you have.
It sends a payload every 60ms for every mode actually, even the constant mode.
So, there is no variation of "dead" time.
What we can do though is make it a uneven waveform.
I did see this in the sniff too, but I thought it was a glitch.
Let's use the lowest level as an example. It changes speed every 4 broadcasts, which is 240ms with total cycle at 480ms.
The master sometimes would change speed with 5 broadcasts for on time and 4 for off time, which would make the cycle be completed in 9 broadcasts, instead of 8 resulting in a total cycle duration would be 540ms.

[dedvalson]

So I gather that what you are telling me is that the master sends a "current speed" to the slave every 60 mSec, is that correct?

What I am seeing though on the Vortech Master is much finer control than 60 mSec intervals.

Based on that, I wonder if maybe the Vortech master is using non-integral number of broadcasts per cycle. By that I mean that the master could creates a waveform of some arbitrary frequency determined by the current pulse settings. That wave could then be "sampled" every 60 mSec and the result sent to the slaves. That way the pulse cycle could be any frequency, not just a multiple of 60 mSec, much like digital audio can be any frequency, not just a multiple of the sampling frequency.

Does that make any sense?

Don

[rimai]

Yes, correct. The master sends the current speed every 60ms.
The slave becomes a dumb terminal when it is set as slave... It can only do what it is told
If the master stops sending data, the slave stops at its last state.
So, the master needs to send what speed the slave needs to be at any given time.

[rimai]

However, now thinking of it, we can make it a really fine tuning machine.
We don't really need to send the payload every 60ms.
We can send it at whatever frequency we want.
So, if we send a payload to put the slave at 0% and send another payload to put the slave at 100% after 342ms, we got a really precise control of the cycle.
What do you think?

[dedvalson]

That makes sense to me.

That was kind of what I meant by the "dead time". If it takes 60 ms send a command then we wait 5 ms that is a 65 msec cycle. Your example would be a 282 msec dead time (342 - 60).

I wonder if the slave mode isn't more active in the "Smart" modes. I ask that only because the slave flashes white / orange / teal in the ecosmart modes where it is on solid in the other modes.

Don

[dedvalson]

Would you like me to take a look at doing this?

Don

[rimai]

I'll try to get something put together over the weekend.

[rimai]

Try this one.
Use mode 12 (Short Pulse).
It is still using 8ms resolution.
The minimum pulse is 240ms, which would be duration=30.

[dedvalson]

Roberto,

So, more than six months later I finally get back to you on this. Life has been very busy.

Anyway, I downloaded and installed the 1.1 code above and tried running it in Short Pulse mode (12). It appears that it isn't much different from the previous version. The original modes still work fine, but the High Resolution modes (12-14) are sporadic, like we are still missing commands. In mode 12 the Vortech works fine if the duration is set to 30. But if I set it to 31, misses every 5th or 6th cycle.

So it works, but is not regular, it is sporadic.

Thanks,

Don

[dedvalson]

It also appears that mode 14 does not work at all. It just turns on and stays on.

Don

[rimai]

Just to try to replicate the same stuff, which libraries version are you running?

[dedvalson]

It looks like 1.0.7.

I can easily change that if it would help.

Don

[rimai]

I did not have time to look into this and test yet, but I'm pretty sure it is because of the Radion integration.
Can you try commenting line 791 on ReefAngel.cpp??
https://github.com/reefangel/Libraries/ ... l.cpp#L791

[dedvalson]

You were right. That Fixed Mode 12 (and Probably Mode 13, I didn't test it). But Mode 14 is still totally dead.

This is great, now I can make big waves in the aquarium.

I would love to get 14 going though. If you would like, I can help with that.

Don

[rimai]

14 is long wave. Isn't the original 4 good enough?
It doesn't need the same precision as the 12, right?
I've logged the issue for the Radion integration
https://github.com/reefangel/Libraries/issues/99