Issue 204 fixed (Tx Batt spoken)
[X9D] It was impossible to avoid a Format on EEPROM Alert
[all] Function v1==x modified to v1~=x (needs to be tested)
Developers list updated
This feature allows use of a transmitter module 'caddy' PCB, which facilitates
automatic DSM2(X) or Fr-Sky transmitter module switching, without having to
swap TX module on the back of the radio. Two antennas are installed on the
radio instead of attempting to switch 2.4GHz RF signals, for reliability. The
TX Caddy circuit schematic and PCB layout can be found in the gruvin9x hardware
project.
I am not really expecting anyone else to implement this feature. But it's there
for those who might and adding it to trunk prevent me having to manually port
the feature to new versions, each time I update my field radio.
-- Gruvin
See comments for r1577 for details. Short version is that I found
a deeper root cause for the problem and corrected that instead
of the previous fix, which turned out to be a band-aid only.
I found that wdt_reset() was not being called in the scheduled interrupt
iservice routine because HEART_TIMER_PULSES was not being flagged in
serial transmit interrupt. This is needed because in DSM2=SERIAL mode,
there are no bit-bang functions being used and thus no HEART_TIMER_PULSES
'heart beats' to record.
I am at a loss as to how or exactly when this bug crept in. I have gone
over everything I committed since r1380 but cannot find anything
directly related. So I just don't know. But it's fixed now. Yay \o/
I also added/edited a bunch more code comments along the way to finding this.
-#if defined(PCBGRUVIN9X)
+#if defined(PCBGRUVIN9X) && defined(DSM2_PPM)
DSM2=SERIAL mode continuous WDT reset problem still present. Still
can't figure out why. Still working on it. :-/
Gruvin.
output frame, where correct pulse polarity was not always set
until the second call to setupPulses, from within the PPM mode
pulse train interrupt handler.
I tested proper function in PPM mode on the logic analyser
before committing.
adjustment is NOT required for the stock board. Thus, all the problems Cam and
I have witnessed appear to apply only to the ATmega2560 chip -- bringing the
total number of design bugs in said chip that we alone have now found to 3.
I do not have any ATmega128 based boards to runs tests there-on.
The only change here is to the code comment on the same topic.
only, until more timing tests on stock board can be done.
In case you're wondering, I'm planning on using the PB7 back-light
conection on an otherwise unmodified board, for those tests --
since PORTH isn't available and all. ;-)
and compensated for main clock synchronisation to get accurate 8us bit
lengths, as measured on the logic analsyser.
Specifically, all 1 and 0 bits now measure 8.000us in length, instead of
varyting from 6.250us to 10.750us, as before.
NOTE: A similar len-5 / len+3 compensation is almost certainly required
to improve bit timing on the stock board, in software bit-bang mode,
but I did not want to commit such a change to trunk without being
able to bench test it first. The values might differ slightly, due
to the number of instruction cycles executed before the actual
PORT B bit toggle code is reached. But it will NOT be the same for
both 1 and 0 bits.
$ make ... PORTH_TIMING=YES
See code comments for details. This is used to analyse real-world timing of
mixer interrupt, setupPulses and PPM or DSM=SERIAL or DSM2=PPM data output
streams.
NOTE: Not compatible to SOUND=YES (SOMO14)
I can't compile the current trunk code, due to some Python error. But the fix here is important.
An #ifdefined was found to be in the wrong place in pulses_avr.cpp -- 99.999% certain. Am I right?
WARNING: All protocols shoul dbe testing on stock board again.
Fixed a number of problems relating to the (dis)enabling of hardware
switched PPM_OUT for the G9XV4 board. I also broke a lot of stuff along
the way over several previous commits, as I slowly learned how all the
code went together and the 'whys' for some stuff. My bad.
In other words, this commit finally has DSM2=PPM mode working on the
G9XV4 board without breaking a bunch of other stuff -- hopefully.
!! STOCK BOARD TESTING NEEDED !!
I am pretty sure I have not broken anything for the stock board code --
BUT it MUST be tested before the next release, because I have made quite
a few changes in and around that code.
bsongis@gmail.com