PDA

View Full Version : Hi everybody! (Introduction to this board)


Pages : 1 2 [3] 4 5

jointer
04-22-2011, 08:05 AM
Them...
If i understood right, the BEC in Jive and WR is the same type, switching regulator.
WR is most favorite and reliable brand, definitely better then Castle BEC.
WR Super BEC is about 1/3 size of Jive, so i think (and hope) it is built to the specs.

dl7uae
04-23-2011, 07:07 PM
We have a new configurator JLC4 (http://62.153.249.80/jlog/wp-content/uploads/2011/04/JLC44004.zip) (version 4.0.0.4), One-for-All, JLog 1 2.4 ... 2.6[.n], JLog1 2.7[1], JLog2 3.1, the new 3.2 and 3.3 A/B ("JTX", homebrew JLog telemetry with XBees), as well as the Powercroco CMT JLog1 setup.

Although there is no version marker contained in CONFIG.txt and it wouldn't be possible to integrate that subsequently in the different firmware flashes, JLC4 is almost unerring in recognizing the version during the read-in of the config file. Only JLog2 3.2 can be misjudged as 3.1 if the type of alarm line #1 is "switched" (and not "interval" or "flash" or "Morse") and "telemetry" is not Unidisplay.

The challenge was a JLC for version 3.3 (D.I.Y. telemetry with XBee), but it was a wish of a user to have also one JLC for both, JLog1 and 2.

Voila.

Tom

Heli G
04-24-2011, 05:42 AM
We have a new configurator JLC4 (http://62.153.249.80/jlog/wp-content/uploads/2011/04/JLC44004.zip) (version 4.0.0.4), One-for-All, JLog 1 2.4 ... 2.6[.n], JLog1 2.7[1], JLog2 3.1, the new 3.2 and 3.3 A/B ("JTX", homebrew JLog telemetry with XBees), as well as the Powercroco CMT JLog1 setup.

Although there is no version marker contained in CONFIG.txt and it wouldn't be possible to integrate that subsequently in the different firmware flashes, JLC4 is almost unerring in recognizing the version during the read-in of the config file. Only JLog2 3.2 can be misjudged as 3.1 if the type of alarm line #1 is "switched" (and not "interval" or "flash" or "Morse") and "telemetry" is not Unidisplay.

The challenge was a JLC for version 3.3 (D.I.Y. telemetry with XBee), but it was a wish of a user to have also one JLC for both, JLog1 and 2.

Voila.

Tom

Thanks Tom, itís great to see the progress youíre making. Now if only Futaba can release that new telemetry TX!!

dl7uae
04-24-2011, 06:41 AM
Let's hope that the display, the appearance of sensor data and its setup, will be as flexible as the S-Bus itself is or will be;)...

Heli G
04-24-2011, 07:29 AM
Let's hope that the display, the appearance of sensor data and its setup, will be as flexible as the S-Bus itself is or will be;)...

+1 :thumbup:

jointer
04-24-2011, 02:02 PM
We have a issue, Tom.
Jeti telemetry.
Sometimes, when the system is powered up, the JetiBox mini will start in JLog2 configuration mode, showing incorrect settings. We can exit the config and after entering it again, everything is right.
Latest 3.2 firmware.
We will test tomorrow again, because we done only 2 flights due to high wind, but it happened in roughly 40% of power-ups.
Edit: capacity check against EagleTree also tomorrow, i hope.

dl7uae
04-24-2011, 04:57 PM
The "issue" is well-known, Petr, we already tried damping it by some provision in the firmware - but the chances for the logger are marginal. JLog cannot differentiate who it was sending acknowledge/keycode over the terminal bus.

It seems to be a bug in the firmware of the JETI Tx module. Keys, never depressed for the JLog, go through if connecting to Mx.

In most cases of that "issue" the logger landed in jbJLC - but sometimes in a strange manner that all values displayed are wrong.

The easiest way to avoid this is to have throttle a little above zero, at 1% for example.

Tom

dl7uae
04-25-2011, 06:53 AM
mAh...

Petr, a bit too late for your today tests, sorry.

Look here (http://62.153.249.80/jlog/downloads) under mAhrs....

Tom

Vinger
04-25-2011, 10:57 AM
Hi Tom, I am a little confused about the firmware versions. Currently running v3.2_3.29 and this works fine. I do not have any telemetry connected to it and purely use it as a logger. Should I follow the two step procedure to upgrade to 3.30?

jointer
04-25-2011, 11:25 AM
Thanks for help Tom, we will try that throttle thing next weekend.
From this weekend we have this mAh tests with the previous firmware:
2055mAh from JLog2 discharged
2260mAh EagleTree discharged
2380mAh Tema SCD 300 charged back (no balancing).
Type of flying was easy flying with some soft 3D.

I can confirm the JLog captures higher current spikes, Eagle logged around 93A and JLog spike was 107A.
BTW what is difference between I-motor and I-motor/Int?

dl7uae
04-25-2011, 12:48 PM
BTW what is difference between I-motor and I-motor/Int?
-----> manual ;)

Integrated motor current. All other loggers do integration on values, JLog does not. To help to learn about the difference and the interpretation of real-time values, especially regarding resulting "power", I added Imot as integrated value, as well as power/int (Ubat * Imot/int).

-----
mAh: The difference is about 10%. Guess, your PWM is a little high (-->throttle). Try the mentioned test version in the download, based on the 16Q model which JLog2 uses to calculate Imot. Bet, that cures.

Tom

dl7uae
04-25-2011, 04:25 PM
Oops, overseen it!
Hi Tom, I am a little confused about the firmware versions. Currently running v3.2_3.29 and this works fine. I do not have any telemetry connected to it and purely use it as a logger. Should I follow the two step procedure to upgrade to 3.30?
In no case 3.3! 3.3 is a very special release, JLog "Air" and "Base", my own toy, homebrew telemetry with TWO JLogs and 2x XBee.

3.2 is the current standard release.

If you do not use the Unidisplay, no telemetry at all: No.

Well, we are currently in a very special phase, "burn-in" :), new findings from practice of usage, wishes, sometimes tiny bugs, often not of interest for the majority, - like the correction for the live stream via USB with 57600 baud lately. - I know that already from JLog1, it will calm down soon.

And I already have the next one, new firmware 3.2, modified JLC4.., but did not upload yet to avoid too much confusion. A tester of a heli magazin wishes to have "power" with MPX telemetry. So I moved external temp #5 out and mpxPWRint in, in the firmware as well as the configurator.

Wait a bit with the next update.;):)

Tom

Ohh, I forgot: You may only update with the firmware flash, step one is only needed if you intend to use Unidisplay (fix display parts in EEPROM to save RAM).

jointer
04-25-2011, 04:37 PM
Not seen that in manual, i have probably bad eyes. :)

I hope it was clear in the mail - it was counting less if i (my friend, to be exact) was flying lighter.
When flying much harder, it was closer to charged capacity, quote from mail:

reported/charged back in lightly flown heli with Jive 80 / 12S:
2Ah/2.35Ah
2.2Ah/2.5Ah
in the same heli harder 3D flying, Jive 120:
2.42Ah reported / 2.55Ah charged

Based on our weekend tests, we see about 8-10% less capacity compared to EagleTree.
We also calculated that we charge back about +6% more mAh then EagleTree is reporting.
Rougly.

Our point is it is better to have higher mAh reported in telemetry, because lower JLog reading can cause the battery to discharge too much.
We also done some capacity testing, not related to JLog logging, for almost 3.8Ah taken out with charger, we charge back 4Ah.

But do not worry, we just measure and test too much - we will test the new firmware if next weekend the weather will be good and report back.
Thanks anyway!

dl7uae
04-25-2011, 05:03 PM
Well, Petr, I think also, better too much calculated than too less.

With the motor current pure into mAh (following the 16Q model of the current calculation in JLog2) we have only +2..3% of mAh if PWM is on a moderate site (throttle <60%) and up to +12% with PWM always at 100%. The 16Q acts in the upper region mainly.

So I'm just thinking about to generally go on the 16Q with Imot in mAh and that's it...

Tom

jointer
04-26-2011, 02:24 AM
Throttle or PWM?
Because i have about 65% PWM for 23% throttle, quite a difference in values.
Anyway i do not understand anything from the english description of the Capacity firmware update.
Some sentences does not make any sense and i have no idea what you mean by 7Q/16Q.
I do not need to know that, but the description is totally confusing.

dl7uae
04-26-2011, 04:48 AM
I do not need to know that, but the description is totally confusing.
Oops.
I do not need to know that
It is my ever lasting failure always to want to explain everything. I should change that, quickly.

jointer
04-26-2011, 06:58 AM
Explanation is fine, but you are so deep in it, so it might not make any sense to "common" users.
And i think i am quite technical person.
Please be aware i do not mean it bad, i am just saying i did not understand what you tried to explain.
Others might be better with it.

dl7uae
04-26-2011, 10:41 AM
OK, you're right.

Anyway: "Q" meant "quadrant". The motor current, from the raw value measured by the JIVE, is processed in "quadrants". The quadrants are mainly defined by the moving value of PWM.

With JLog1 we had 7 quadrants of that processing, the highest quadrant was resulting in a Imot a bit too low. I knew that but left it because I was a bit "shamefaced" before the first JLog came out, because I thought that the users wouldn't believe those real-time values. They knew only integrated values before (from other loggers). The other reason was that with the processor of JLog1 we do not have enough memory for a more granular processing.

With Jlog2 the processing of the motor current is in 16 quadrants, accuracy at the lower and top end also.

Because JLog1 users were reporting accuracy of the "mAh" I used also a modified 7Q (now you know what I mean;)) for the motor current going into "mAh", whereas the logged/displayed motor current is based on the 16Q.

Now it looks like that this was no good, better to use the motor current as coming out of the 16Q also for "mAh". (The test version in download does that.)

The impact on "mAh" compared to the former implementation is:

With throttle <=60% (heli governor mode, not too high throttle for head room in PWM) we will see a plus of about 2..4%. With high throttle, PWM always at 100% or almost 100, the plus will be 10..15%.

Anyway.. The problem with "mAh" is always, to know who the appropriate reference can be... I'm about to think now, it was a mistake (by me) to stay with the 7Q from JLog1 than simply to use the current from the 16Q otherwise used by JLog2, - simply cumulating the calculated current in log/display through the time steps, that's it.

Did I manage to answer the questions I by myself let come up?:)

Will try further not to use too much details, internals, that must be confusing and left an impression of unprofessionality in the end.

Tom

dl7uae
04-26-2011, 07:34 PM
New preliminary test version 3.2.1 in download (http://62.153.249.80/jlog/download).

With that version also your two issues are handled, Petr, mAh and JETI.

We recorded the JETI terminal bus as seen by JLog, means the bus from the JETI Rx, "Mx": Hey, pure "data salad" there if the box is not connected to Mx. Is it floating then?... No idea what's going on, but we found a reliable workaround against the impact on JLog. Always landing in telemetry page 1 now.

"Preliminary" because the two other changes concerning Multiplex telemetry are still untested yet.

Tom

jointer
04-27-2011, 04:02 AM
Tom, i almost get the explanation now. :)
But it should be enough to write something like that:
"This new firmware is processing mAh with more detailed algorithm, the calculation method is now the same like for Imot, so the capacity calculation should be 3-12% higher then before. New hardware of JLog2 allowed me to do that, old JLog hardware was not capable enough and until now both of them were using more simple calculation."

Or something like that, keep it simple.

We will test the new new firmware then. :)

I have theoretical question.
Battery energy units is Wh, watthours.
In theory, during discharge the voltage drops, so current must raise to deliver the same work (more mAh consumed). During charge, the voltage raises, so less capacity is delivered back, but the same Wh.
What is wrong with this simple thoughts?

dl7uae
04-27-2011, 07:01 AM
I have theoretical question.
Battery energy units is Wh, watthours.
In theory, during discharge the voltage drops, so current must raise to deliver the same work (more mAh consumed). During charge, the voltage raises, so less capacity is delivered back, but the same Wh.
What is wrong with this simple thoughts?
Hey, Petr, interesting, the same thing, I have a snarl in brain with..:)

Of course, during discharge the Eta of the battery (regarding the stored energy) is much lower than during charge. This is because of the current in relation to the internal resistance. We have much more energy to fill in than we get from the battery during high-current discharge. The battery is heating because of dissipation loss....

So far... But I think, because we measure only capacity, mAh, - and this is not the same as "energy", - current is current, per time step here.

Tom

jointer
04-27-2011, 09:37 AM
We know how high is charge/discharge efficiency, Wiki says it is 99.8%, which is really very nice.
There are some thermal losses, by my experience higher on discharge and lower on charge.
Then why i discharge 3.8Ah and charge back 4Ah? That is 5-6% loss.

dl7uae
04-27-2011, 09:49 AM
Then why i discharge 3.8Ah and charge back 4Ah? That is 5-6% loss.
At first: You know already the German saying, I believe: "Wer misst, misst Mist." Freely translated: Who measures, measures crap.;)

Loss in balancer.

Loss in other parts of the charger?

Loss in connectors.. Okay..., but...

We charge "energy", we discharge "energy", partly as input, partly as dissipation loss..

But we measure in "mAh", current cumulated over time steps, not "energy".

It keeps to be difficult.:D Where are the theoretical physicists?

jointer
04-27-2011, 11:46 AM
Yeah... the problem is what is right, discharged capacity or charged back, what it the reference point...
Loss everywhere, charging, discharging, you measure on the side of motor, EagleTree on the batteries with Hall sensor...

Anyway if the JLog will give reasonable numbers which could be trusted for "fuel gauge", then it is good enough for me.
I know the primary purpose was logging, but the telemetry is much more interesting, because no external sensors (which could fail or adds weight) are needed.

dl7uae
04-29-2011, 04:06 AM
Early enough before the weekend:

Testing of the preliminary release 3.2.1 32.107 have been completed, 3.2.1 is the current release now. See the download section of j-log.net.

Tom


Attention! Due to a malicious bug in the crappy ATMEL compiler the just released 3.2.1 32.107 had to be replaced with 32.108 few minutes ago! I apologize for the inconvenience.

(If somebody likes to know: A variable, although defined to be "volatile", lost its content during runtime. Result: FTDI speed and type of the pulsed alarm line forgotten on the fly. I love that compiler...)