Resolution of RF Vortech command

[dedvalson]

Hi,

I have been using my RF module with my Vortech for a while now and have run into an issue that I don't know how to solve.

The main Vortech control command is

RFClass::SetMode(byte mode, byte speed, byte duration)

The duration argument sets the pulse speed in modes like the Nutrient Transport Mode. However, it appears that the resolution on duration is pretty low. Changing the duration value by 1 step changes the actual pule rate on the Vortech too much. It seems like the durations above about 30 are useless and the steps below that aren't tight enough to hit a particular resonant frequency in the tank to cause wave action. The steps when using the native Vortex interface are much tighter.

I don't know if the RF protocol allows tighter control, but it seems like it must because a master Vortech can set a Slave Vortech using much smaller steps than the RA can. I can see in the source code that the duration is being written directly out to the wire.

I am wondering if maybe the master Vortech controls every single pulse of the slave one over RF?

Any thoughts?

Don

[rimai]

Which mode in particular?
The resolution for duration of short pulse is 10ms and long pulse is 1s.
That limitation is imposed by the ecotech driver.

[dedvalson]

I am using SmartNTM mode.

But the resolution seems much more like 100mSec than 10 mSec.

I will time it in various values and let you know exactly.

Don

[rimai]

Oh, actually yes... I'm sorry... 100ms...
value 10 = 1 second

[dedvalson]

OK, that is what I thought.

There must be something else going on when the Master is running the Slave because it sure seems like the steps are much smaller. I wonder if there is a different protocol or command or something.

When I ran without the RF module I was able to tune for great wave action in the tank. I can't seem to hit that frequency with the RF Module. I will try again.

Don

[rimai]

Is it the same if you use short pulse?

[dedvalson]

I went home at lunch and ran some quick tests. I didn't try short pulse yet but in SmartNTM the numbers do seem to correspond to 100 mSec intervals. However, it is the "on" time, so a value of 10 results in an on time of 1 sec and an off time of 1 sec. Thus each increment changes the cycle time by 200 mSec, which is too coarse to hit tank resonance.

When I used the ecotech driver controls directly the steps were almost imperceptable. I will try the short pulse mode tonight.

Don

[dedvalson]

Roberto,

Can you tell me a little more about how the RF module controls the slave mode vortech. Does the RF Module just send out a single command like "Go into this mode at this speed" or does it control every pulse of the Vortech slave. I can see that the software only sends down a single command to the RF Module but I wondered if the RF Module itself is sending commands continuously or only at a mode change.

Don

[rimai]

The controller only needs to send the command once and the RF module takes over and send commands to slaves continuously.
I can change it to make it a less than 100ms resolution, but the duration values are limited to 255.
So, if the resolution is 1ms, you will get 255ms at most.
You are working on around 1 sec total cycle, right?
We could make it 5ms resolution or 10ms for easier math.

[dedvalson]

If you used 5 mSec that would give a maximum total cycle time of 2.5 seconds (1.25 on, 1.25 off). I think that might be too short for many tanks. Perhaps 10 mSec is the best bet, that allows cycles up to 5 seconds. Beyond 5 seconds slow pulse mode could be used.

I wonder if while you are doing this if it would be worthwhile to change the resolution of long pulse mode (if you can) to something less. The current value allows a cycle time up to 8 1/2 minutes (4.25 on 4.25 off). That is so long that it doesn't really even seem like a pulse mode. A resolution of either 500 mSec or 250 mSec might make more sense there. Just a thought.

I am assuming this would be a global change so we need to take into account the greatest number of users.

Don

[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