PPM pulse not stable about headtracker HOT 47 CLOSED

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.

from headtracker.

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.

from headtracker.

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

from headtracker.

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.

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

Let me know.

from headtracker.

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.

from headtracker.

Can't download the receive config. Transmit okay.

Are you seeing jitter with the Bluetooth connected too?

NM: missing the C

from headtracker.

Try this:

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

Somehow I mangled the link!

from headtracker.

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

from headtracker.

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

from headtracker.

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!

from headtracker.

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?

from headtracker.

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.

from headtracker.

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

from headtracker.

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.

from headtracker.

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

from headtracker.

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.

from headtracker.

Ok.

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

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

from headtracker.

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?

from headtracker.

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

from headtracker.

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.

from headtracker.

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.

from headtracker.

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!

from headtracker.

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.

from headtracker.

@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.

from headtracker.

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!

from headtracker.

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

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

Rob

from headtracker.

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

from headtracker.

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!

from headtracker.

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.

from headtracker.

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?

from headtracker.

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!

from headtracker.

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.

from headtracker.

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!

from headtracker.

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

zephyrproject-rtos/zephyr#37047

from headtracker.

Thanks for all your efforts.

from headtracker.

Great stuff!

Will update once published and test.

from headtracker.

Published. v2.03

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

from headtracker.

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!

from headtracker.

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?

from headtracker.

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.

from headtracker.

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

from headtracker.

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!

from headtracker.

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
4*3.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.

from headtracker.

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!

from headtracker.

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

from headtracker.

Just dropping this here for you:

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

I quite like how it turned out!

from headtracker.

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

from headtracker.