PPM pulse not stable

[robthomson]

An issue exists when using a second BLE device as a receive unit.

There is a constant 'jitter' on the channel - even when the transmit module is turned off.

The result is that the servo on the head tracker will never stay centered. It is always moving 0% - 1% 0% 1% etc.

I have tested by sending pan on channel 5; using 8ch ppm. Jitter exists. If I drop to 4ch ppm (which will not have any servos moving) the jitter disappears.

This issue occurs even when the transmit module is off; so I suspect it is something to do with the receive module ppm output code.

[dlktdr]

Version 2.01?

All of your channels are set to off on the receiver one?

Maybe send me your saved .ini from the remote board. I'll see if I can reproduce it here.

Also do you have PPM input on by any chance on D9.. I've seen it pick up the ppmout signal on the floating ppm input pin then cycle on/off and cause a feedback loop. Shows up as a whole bunch of PPM detected/lost signals in the serial window and jumping around. When connected via BT it overrides the all PPMinput channels (Haven't finished that issue yet #39 ) so it goes stable.

https://user-images.githubusercontent.com/281145/125892084-1e6c85d3-c5c9-426c-9da7-8c54119a45cb.mp4

On the scope I see about 1.5us of jitter normally, which I doubt would be noticeable on the servo.

Let me know.

[robthomson]

Please find the following files:

Receive Module Config https://drive.google.com/file/d/1LslU-WOd8mNOVTewG6gqKkBkn5Awy78v/view?usp=sharing

Transmit Module Config https://drive.google.com/file/d/1MquGEGO_G-0XKYZjURwiHnG4B5iccxHH/view?usp=sharing

Video of Issue as comes up on the Jeti https://drive.google.com/file/d/1AQo_Ul1OyytHxrZxacV2v8psqA3fYT4N/view?usp=sharing

I have checked settings as per your video and do not have that configured as speculated.

[dlktdr]

Can't download the receive config. Transmit okay.

Are you seeing jitter with the Bluetooth connected too?

NM: missing the C

[robthomson]

Try this:

https://drive.google.com/file/d/1LslU-WOd8mNOVTewG6gqKkBkn5Awy78v/view?usp=sharing

Somehow I mangled the link!

[robthomson]

And yes.. jitter occurs with and without the bluetooth connected.

[dlktdr]

I can't see an obvious issue in the code. Will have to dig a little deeper to see if it's the hardware/OS/code.

I can increase the resolution of the timer and post a test FW to see if that makes a difference. Stay tuned

[robthomson]

Many thanks.

Issue seems pretty 'regular' almost like a 'tick' being sent.

My first thought was that maybe you needed to add an additional filter to the output stream.

Essentially not to 'move' unless the pulse stream us changed by more that 1 value.

So.. 1599 - 1600 - 1601 would still produce an output of 1600.

But not entirely convinced that's the issue!

[robthomson]

Found something interesting.

On the jeti I am powering the device with a small 'step up' pololu invertor. This is essentially to up the voltage as the jeti only runs on a 1s lion.

If I run the unit on the usb port - the issue drastically improves.

It makes me wonder if there is some sort of power ripple going on.

Curiously.. if I power up the device with USB first.. then turn the radio on.. then disconnect the usb. All seems a bit better.

Is there some sort of clock speed issue going on?

[dlktdr]

Do you ever see the Channel output values moving in the GUI to a value other than 1500? If not I suspect it's something electrical related, or Nano hardware.

I've been running on USB power or a 2s battery here. Which are pretty clean power.

Since it's a step up switching converter what might be happening is because the BLE pulls so little power the jump is every time the power supply switches it's inductor on and off and re-charges it's capacitor. I assume it's boosting it to 5v?

When a SWPS in running in discontinuous mode (current in the inductor drops to zero) with too little load the voltage likes to spike. The interval your seeing might be the switch. Usually solved by adding a bigger capacitor on the output so the spike is lower & delay gets longer ~100uf Capacitor.. OR drawing enough power to run it in continuous mode (always current in it's inductor) by placing a load resistor on the output. Would need to know the full load current if you wanted to run in continuous mode.. And it's a waste of battery too. but could try a 100ohm resistor to see if the twitch gets faster.

Since your Jetti Hw is most likely 3.3v these days is there somewhere you could tap into it and run 3.3 directly to the Nano? skipping all the extra SMPS's.

I guess looking at the signal on a scope would be ideal if you have one. To see if the timing is actually changing or it's just noise induced on the line.

I'll try here when I'm home from work tonight and try from a few SMPS's and scope the output. Although I don't have any step up (boost) ones.

[robthomson]

Ok.. so I have found a fix. No idea why it works - but it does!

What I have done is to power the nano using the VUSB pin on the back of the board.

When powered off this VUSB input - the signal is suddenly stable.

I have no idea why and would be interested in your electronics knowledge/input to clarify?

Rob

[dlktdr]

There is one extra diode D2 in series with that so you can have the USB and vin Connected safely at the same time. Really wouldn't expect that to make much of a difference.

FYI if you have it wired like this make sure you only power via USB or your supply at a time so you don't cause power flow the wrong way into your computer.

But it works.. That's what counts.

[robthomson]

What would the imact be of 'bridging' the VUSB pins?

[dlktdr]

If you solder that bridge on the back it just connects the USB 5 bolts to the 5 volt pin on the nano. Normally that pin has nothing connected.

If you had a project that needed 5 volts and you were powering off the USB is kind of a situation you would use that. In your case you could solder that bridge and connect your wire to the 5 volt pin instead might be more secure.

[robthomson]

Ok.

Well.. on the plus side - all working now!

Very strange on the VUSB thing. But at least a fix!

[robthomson]

Question.. you say I could power it off 3.3v.

The jeti outputs 3.3v on the internal jack. How can I make the ble-33 be powered off 3.3v?

Looking at the specs -the operating voltage is 3.3v. But VIN expects 4.5 - 21v

Would I just connect it to the 3.3v pad on the BLE?

[dlktdr]

Yes that's right.

To be perfectly correct you should cut the 3.3v bridge on the back of the board. This will isolate the internal regulator. You can always solder it back together if you need in the future.

You will need to power it from the radio to use USB after as it will no longer generate it's own 3.3v

See the bottom of this page for the photo where to cut it.

https://www.arduino.cc/en/Guide/NANO33BLESense

[robthomson]

Just tried that -no joy. IT works.. but noise returns.

I have reverted to a step-up from 3.3 to 5v; and the power input on the VUSB pin!

Strange.

[dlktdr]

That is strange. I'm going to do some investigation tonight trying it like that on 3.3 and connected to my radio. Can you send me a photo of your wiring and ppm cable so I can try to match best as possible.

[robthomson]

Nothing particularly fancy.

• I snipped the 3.3v pad.
• wired the 3.3v power to the 3.3v pin
• wired gnd to the gnd pin next to vIn

In the case of the JETI; there is a COMM port inside the radio that provides

POWER GROUND PPM IN PPPM OUT

I simply wired the respective pins to the respective pads on the board. Wires are no more than 3cm long each!

In the case of the working solution; I simply step up the voltage and wire the vIn to the top pad on the VUSB pin - and all works.

Clearly the issue is not the step-up. Makes little sense really!

[robthomson]

Any idea what the specification is of the little diode on the VUSB line?

I am wondering if some noise is in some way going back down the VIN line that the diode stops. Maybe putting a diode on the 3.3v will stop this occuring when powered this way.

[rotorman]

@robthomson Have you checked that the radio can source enough current for the Nano at the 3.3V rail you are currently tapping it at?

A far fetch - have you tried putting a resistor, such as 51 Ohms, in series with the PPM line to limit the surges of pulses?

If, after checking both above points, the issue is still persistent, you could try to get a very quiet power rail, by implementing a DC/DC boost converter, such as Traco TBA 1-0311, to elevate the input of 3.3V of your Jeti first to 5V. In a second stage, drop the level back to 3.3V with a linear voltage regulator, such as TC1262. Some energy will be wasted with such method, but you will be rewarded with a very quiet power rail for your Nano 33 BLE.

[robthomson]

I do get a clean supply using a boost regulator already - just its a bit of a waste of energy doing this. No big issue. Just curious why it happens!

Suspect a resistor may be the fix!

[robthomson]

Oh.. as a point of interest. With my current VUSB power..

I see noise right up until I turn the BT link on.

Rob

[rotorman]

too high ripple of Nano MPM3610 w/o significant load?

[dlktdr]

So I cut the 3.3v solder bridge and verified powering via USB no longer works. Then used my power supply to supply 3.3v directly. I programmed with same version. Worked great no change. Then.... I unplugged USB after programming and I get jitter like crazy.

Seeing about 18.2us jitter. which is the same 2% like your radio is picking up. My Taranis also went crazy showing 0, -2 the same result your getting.

I haven't looked further yet.. but yes some sort of power issue. Will keep you updated to a solution.

[dlktdr]

May have found the cause probably software, but not the receive code.. The processor is going to sleep, even though I thought I disabled it. But I don't see that line in the Zephyr config. anymore.. woops :) I had it in there at one point. Also why the more features you turn on, e.g. Bluetooth the less the processor is going to be idle and sleep.

When supplying via VUSB, it forces it out of sleep mode. Going to sleep would account for the change in clock timing too.

Thanks @robthomson for the insight. I'll see if I can get it to stop sleeping.

[robthomson]

Aha.. that would make sense then. Clearly 3.3v does not stop sleep either.

Will be fabulous to get it fixed - I would ideally prefer to avoid running the unit with a step-up in the Jeti as its just wasteful of battery power!

[dlktdr]

Yeah looks like the only thing that actually stops it is putting 5v on the VUSB pin. Working on it as we speak. Apparently that line I had in zephyr config wouldn't have worked either. Think I found a solution just testing now.

[robthomson]

So here is an interesting thing for the jeti radio.

"The PPM output is accessible via internal connector labeled "B". This connector features a non-stabilized battery voltage output in the range of 3.2V - 4.2V (max. 1A) which can be used as a power supply for the connected HF module as well as for the PPM signal output. The transmitter output functions are in the form of a standard PPM signal.

1. PPM input (3V logics)
2. Positive (+)pin
3. Negative (-)pin
4. PPM signal output (3V logics, configurable in „System "

Whats the chance that running on 3.3v port will be a problem without a regulator?

[robthomson]

Spose I will need one of these:

https://coolcomponents.co.uk/products/3-3v-step-up-step-down-voltage-regulator-s7v8f3?currency=GBP&variant=45223016462&utm_medium=cpc&utm_source=google&utm_campaign=Google%20Shopping&gclid=CjwKCAjwos-HBhB3EiwAe4xM991Ds8-bwiToYr77Q3GgYfqOY3nMpOhqyu-XbtSWtRWTCbiwcBFdfxoCHk0QAvD_BwE

At least for 99% of the battery life I am stepping down - and not up!

[dlktdr]

The BLE puts out a 3.3v pulse on the PPM output pin, so that's okay on the PPM input (3v logics), which actually means 3.3..

Actually powering the device from that +/- directly to 3.3v on the Nano no I wouldn't. That looks like it's just battery voltage and at a full charge of 4.2 is too high. The Nano calls for max 3.7 I believe, would have to verify, but I know it's lower than 4.2 and will likely damage it.

Yes a buck/boost converter like that would be okay and power direct to the 3.3v pin. Your radio already probably has one of these converters built into it as it's going to be using 3.3 for everything. What did you power it from 3.3v before? I would stick with that source.

If I fix this code I don't see any reason you can't keep using the boost converter and the Nano dropping it too.

[robthomson]

I used the same non stabilised output - but to be fair battery was nearly flat so within tolerance.

I am hoping to just avoid the additional step up process as this just drains power for no reason.

Likely I can find a 3.3 on the board. Will have a dig!

[dlktdr]

Didn't have a heck of a lot of success yesterday. Got the jitter down to 6.6us making some other changes, but it offsets by 20us now when VBUS not applied. Doesn't jump around but still not quite right. Found two other bugs in the process tho!

I've asked for support on the Zephyr group will see If anyone else has any ideas. Will give it another go after work tonight

https://github.com/zephyrproject-rtos/zephyr/discussions/37047

[robthomson]

Thanks for all your efforts.

[dlktdr]

Found it.

Wasn't a sleep issue. When applying 5V to VBUS also forces it to the HF clock source. So when not connected uses the low power/inaccurate LF clock.

Added..

    // Force High Accuracy Clock
    const char *clock_label = DT_LABEL(CLOCK_NODE);
    clock0 = device_get_binding(clock_label);
    if (clock0 == NULL) {
        printk("Failed to fetch clock %s\n", clock_label);
    }
    clock_control_on(clock0,CLOCK_CONTROL_NRF_SUBSYS_HF);

Works as expected. Will get a FW posted soon

[robthomson]

Great stuff!

Will update once published and test.

[dlktdr]

Published. v2.03

Thanks for the help / testing, let me know how it goes

[robthomson]

Tested and working on VIN. Seems good.

I do notice that when the BT is not connected you get a small wobble..

0% 1% 0% 1%

But that drops as soon as BT connects.

All up.. much nicer!

I also noticed that my restore file works when doing a restore in the gui; but does not seem to reflect changes properly when viewing the interface - probably need to update my desktop app!

[dlktdr]

0% 1% 0% 1%

Do your servo's show the same twitching? Guess depends how good your servos are if it will even show that.

Open TX has a trainer calibration function in it to zero the center on the channels, does Jeti have something similar? Might try that in case there is a slight discrepancy between the two clocks what is 1500us. Although it's not much and shouldn't be anything to worry about.

But that drops as soon as BT connects.

All up.. much nicer!

👍

I also noticed that my restore file works when doing a restore in the gui; but does not seem to reflect changes properly when viewing the interface - probably need to update my desktop app!

Can you elaborate on this. Should still be using the same 2.0 GUI. Like after you restore the GUI didn't match the settings file?

[robthomson]

Yup.. Servo does not even show the movement.. Kind of feels like maybe we have a slight center point difference between the centers.

Maybe an option is to not actually send anything if now BT signal is present? This could essentially allow lower power draw while the system is not in use?

The restore.. Just double checked and it was me having a brain fart! Seems to be working OK.

[dlktdr]

Yeah I guess that's the joy of analog a few microseconds of timing different between the clocks will show up as an offset. Probably nothing to really worry about.

I actually want to do a current reading when I get back home tonight since i have that solder bridge cut and to see what is really drawing now.

The current still doesn't show on my power source It's still shows 0.00 so It can't be too much. Need to wire in the milliamp meter. From what I saw online it draws about another hundred uA leaving it in HF all the time. Which might be an issue for a coin cell project but not here.

Just about guarantee those blinking LED lights are the biggest unnecessary draw.

I'll find some numbers and put them on the documentation for reference

[robthomson]

My jeti shows about 20mah draw extra running the step up and the BLE unit.

So very low!

Can you turn the lights off?

I am away for a couple of weeks - once back I will investigate the 3.3v power on the jeti. Will save a few mah!

[dlktdr]

Found some stats if your interested.

V2.03 Powered Direct at 3.3V Non-Sense Board Disconnected from GUI unless otherwise mentioned.

Nothing enabled (BT, PPM, etc..) - 11.20mA Nothing enabled (Led's Disabled) - 7.24mA PPM Out Enabled - 11.27mA PPM Out Ena. BT as Receive (Not Connected, Scanning) - 15.71mA PPM Out Ena. BT as Receive (Connected, non-PARA) - 12.27mA PPM Out Ena. BT as Receive (Connected, PARA) - 11.73mA PPM Out Ena. Tilt/Roll/Pan On (As a wired head) - 11.36mA PPM Out Disabled, BT as Transmit - Not Connected 11.34mA PPM Out Disabled. BT as Transmit - PARA 11.80mA PPM Out Disabled. BT as Transmit - non-PARA 12.43mA

Worst case scenario - BT Receive (Scanning) GUI on, All options Enabled. Rotations enabled, All Analog enabled, 16.03mA

From this I can deduce apx. how much some items take power wise.

7.24mA - Basic Code 4mA - Leds Power + Code Running Blink 0.07mA - PPM Out On 4mA - BT Receive Scanning 1mA - BT Receive Connected 0.54mA - BT Receive Extra Power to Decrypt 0.14mA - BT Transmit Waiting for Connection 0.60mA - BT Transmit Connected 0.63mA - BT Transmit Extra power to Encrypt 0.1mA - GUI Connection

Interesting to see how much extra power it draws encrypting the BLE data on the non-Para BT device.

All in all even Worst Case Scenario it's only 16mA * 3.3V = 53mW.

So on a 4Ah single 3.6v Lion cell, using only 80% capacity could run this for 43.6 = 14.4wH / .053w 0.8 = 217Hours :)

Not assuming the losses from boosting and bucking tho. Don't think we really need to worry about the LED's.

[robthomson]

Nice!

Done some of my own checks and seems worst case with my current step up regulator I loose an hour of run time on the radio.

Considering that with the bt module that still equates to an 18 hour run time.. I think I will be OK!

[dlktdr]

Lol yeah 18 should be good. Pretty good for a single cell!

[robthomson]

Just dropping this here for you:

https://www.thingiverse.com/thing:4912981

I quite like how it turned out!

[dlktdr]

@robthomson Added this to the user designed cases page.. https://headtracker.gitbook.io/head-tracker/getting-started/mounting/user-designed-cases