Logview Program

[mdu6]

Also did another test. I re-flashed the Firmware but this time WITHOUT any pulse.txt file and even without the file present it still was showing 0% (MAX) and 100% (Idle).

I would seem that it always keep the first version of the pulse.txt I did ?

[dl7uae]

Tested everything.

Servo pulse in center pin of OPT, played with several value pairs in pulse.txt.
It just works...
(Question: pulse length is displayed correctly?)

RPM pulse in parallel to above in signal pin of OPT, pulled the red wire to supply the sensor from another source (used the 3.3V coming of the center pin of JLog's s.bus2/s.port port).
Well... rpm was wrong.., not *10 but *2. Forgot that I had to re-implement the ext rpm routine also (for "specialservoCH0").
Tested with a frequency generator as rpm pulse source, with 1 | 10 |100 Hz, corresponding to 60 | 600 | 6000 rpm. Displayed and logged correctly now.

Find attached the new firmware which corrects the "*2 bug".

[mdu6]

Thanks (again) Tom - I will test everything later tonight.

[dl7uae]

A cigarette smoked ..., besides I usually think of a solution. Smoking reduces the oxygen content in the brain, strange that I always have ideas.

rpm:
I suspect your rpm sensor generates very short pulses. Will change the software to be resistant to it.

pulse:
No idea what's happening there.. So let's try this: I make a special firmware setting useful values in the four cells of JLog's non-volatile memory.

I do this tomorrow, here the backup is already running.

[mdu6]

On the throttle % - when you said it is working on your side - this means to me that you have reverse the servo direction and switch the values in the pulse.txt file to still show 0% at idle and 100% at max ? Right ?

[FrankFuss]

Thanks Tom for the firmware update. I have been using this firmware also. I am still a couple weeks away to finishing my Goblin 700 Gasser. I am using a Stator Gator for the RPM pulse, but will need to have the engine running before I know the result. I do have a scope, so I will be able to see what the pulse looks like.

[dl7uae]

OK, but now.

That is a bit complex.. Background is:
Both pins, - center pin for servo pulse, "signal" pin for rpm pulse, - connect to GPIO's (General Purpose I/O) of the micro controller which belong to the same interrupt group. We have to use so called pin change interrupts.

An interrupt has to be triggered on both edges, low->high and high->low. We need that on the "servo pin" to measure a positive (high) servo pulse (only Castle Link Live using a negative pulse). The "rpm pin" measures the time between two high->low edges of a rpm pulse.

We have different frequencies, variable rpm pulse frequencies, - variable duty cycle in the servo signal, - any duty in rpm signal.
The phase angle between the two signals is constantly changing.

Now it is indeed not easy to differentiate between both signals because they terminate in the same interrupt routine. What pin triggered the interrupt? We have to measure times in microsecond resolution at minimum.

All other firmwares for JLog do not have do deal with such a situation.

Anyway.. Made several modifications. That helps but cannot cure entirely. So I implemented on top hazard filters, 10-stage for servo pulse, 1-stage for rpm pulse.

See the attached screen shots. Because both signals interact with each other - interference depends especially on the rpm pulse frequency. Shot 2 shows the activity of the 10-stage anti hazard on top. In shot 3 we're running a higher rpm pulse frequency, - for 6000 rpm on a 1-pulse-per-revo sensor. I think, in practice we'll have at max about 2500 at a ratio of 1:10. (Some minor hazards are rarely still possible in "PulseLen", more effective acting in "throttle": big range --> small range)

I had to extent pulse.txt, 3rd item now to inform JLog that the servo pulse is reverted (not inverted). att #4

All three items are learned by JLog and stored in its non-volatile memory, - changed if pulse.txt has content different from memory. No need to always have pulse.txt on a SD or to run w/ SD at all.

"max len": 3000 at max accepted
"min len" : 1600 at max accepted
"max" have to be less than "min", of course.

Attachment 5 is the new JLog firmware.

----------

when you said it is working on your side - this means to me that you have reverse the servo direction

No, you have, definitely.

[dl7uae]

Forgot.. Device description files for LogView v2.

Strip the extension .pdf from file names.

.lov files are easier to use: open w/ LV, LV learns the device automatically.

[mdu6]

Hi Tom - good news both fixes are good

1) Throttle% now handle servo Normal or Reverse direction

2) RPM seems spot ON - showing 810 RPM on the engine side while I was turning 100 RPM on the main gear.

Reading your previous post (extensive !) the only question I have is the maximum RPM. Since I am mesuring engine RPM, I will be in the 14000 RPM range - will this still work at this speed ?

Thanks again (3) - for the effort and dedication

[dl7uae]

14,000? Thought that you measure at the main gear?

I'll test 14,000 w/ a frequency generator (233.33Hz). I think it will work although the interaction with servo pulse measurement is getting stronger with increasing rpm pulse frequency.

I do that tomorrow. Local time is 3:03 AM, heading to Zzzzzzz...

[dl7uae]

What can you do today that do not put off till tomorrow.
Not only a German proverb, I believe.

233.33Hz == 14,000rpm
Picked a Graupner GR16 receiver as throttle pulse source, running standard 50Hz servo pulse frequency (20ms frame time).

Seems to work, my hazard filter does.

[mdu6]

thanks !

I was (temporarily) measuring RPM at the main gear because it was an easier spot to put something together to double check the measure from the RPM sensor on the engine clutch.

[FrankFuss]

I finally finished my Goblin 700 Gasser and tried this firmware (26-J_Essc-111.126). I am using a Stator Gator for the RPM pulse. Using a 5V regulator to power the Stator Gator, I get a RPM pulse 600uS wide and 3.5V in amplitude. Attached is a picture of what the pulse looks like. I attached a log file (log00053) of a 2 minute run at a constant throttle setting resulting in around 3432 RPM to 4118 RPM according to the governor. There was not much interaction between the RPM and Throttle data in this log file. However, I attached another log file (log00054) of a much longer run where I was varying the throttle some at idle and which resulted in not nearly good data. I selected 1 pulse per revolution and checked the Motor option (see Config file). Is there a better configuration to minimize the interaction between the RPM and Throttle data? Once I get the motor broken in I will typically run between 11500 RPM and 14000 RPM.

[dl7uae]

It doesn't look like interaction, it is the shape of the rpm pulse. That causes then some interaction on top, yes.

I told you that JLog is not prepared for pulse measurement on two pins of the OPT port simultaneously. Possible functional MCU-pin assignment ends up to land in the same pin change interrupt routine for both pulses. As a result the trick is to find out which one of the two pulse sequences (asynchronously, not in phase to each other) has triggered the interrupt. So we measure on both pins (high/low), wait a couple of nanoseconds, measure again. Afterwards both sequences are handled by hazard filters, checking the plausibility of changes in time.

That needs a clean pulse with steep edges. The shape of the low-high edge of the rpm pulse is more that of an analog signal than of a digital one.

That thing needs a Schmitt trigger to reshape the rpm pulse.

------
In parallel I will look for an alternative -- to be able to clearly separate both in two pin change interrupt routines. The crux is that this will need to use JLog's KOSMIK port, - special plug required.
(COM is occupied for Jeti telemetry, s.bus/s.port is pin-sharing w/ COM internally, SPEKTRUM port is pin-sharing with OPT port, the JLog port cannot be used because of decoupling components in pathway.)

------
rpm: Look, this is not a single hazard than multiple errors on the creeping low-high edge. Points on the round edge are considered as low/high, that way emulating non-existent high-low edges between which the time is measured to calculate rpm.

[FrankFuss]

Thanks Tom for your help. The weather is too bad here at the moment to try it, but given the shape of my rpm pulse would I get good rpm data if I measured only rpm and not the throttle? Or, if I used one of the other standard firmwares and measured only the rpm?

[dl7uae]

given the shape of my rpm pulse would I get good rpm data if I measured only rpm and not the throttle?

Hmm.., may be, just give it a try.

Or, if I used one of the other standard firmwares and measured only the rpm?

Same question in the end.

[mdu6]

Hi Tom

After finally being able to do some flying, I just wanted to report that everything worked out perfect ; engine RPM and Throttle servo position are both reported steadily thru the Jlog back to the Jeti Tx

Thanks again, Mario

[dl7uae]

Supi.

[mdu6]

Here is a sample Jeti Log - showing RPM and throttle position as captured by JLOG - very nice !

[dl7uae]

Could look better (not the data, the drawing principally).
In addition, the update rate of data in a telemetry is slower than local log recording by JLog, - and data going into telemetry is made a bit "human-like", integrated.

Post the device ID of your JLog, please.