J-Log.eu - Forum

JLog3 (S32) firmware 1.24 w/ a modification for JETI:

Topic: alarms sensor-->terminal ... "terminal": transmitter, Profibox, TU modules

JETI continues to play letter lottery (an alarm is "coded" as a letter). At the time JETI's first transmitter hit the market (before we had TU and Profibox) that issue appeared for the 1st time: TU modules and Profibox worked w/ uppercase letters, whereas the transmitter wanted to get lowercase letters only. So I changed it, upper to lowercase (in JLog2.x).

Now the transmitter DC24 denies to eat alarms from S32, wants to see uppercase letters.

OMG... It seems difficult to agree on something in the same development department, only upper or lowercase or even both...

S32's firmware version 1.24 therefore sends an alarm alternating as lowercase, then uppercase letter. The repetition rate of a single alarm or the time to send the next active alarm is 2.5 seconds in JLog. By that alternation halfs it to 5 seconds.

------

SPEKTRUM:

A hard time began..

Months ago Andy from Horizon sent (internally) a rather huge paperwork about their plans for the future, especially about the planned use of Multiplex' SRXL in a bidirectional manner, SPEKTRUM form.

Okay..., so let's implement SRXL telemetry on top (besides X-bus). Everytime when I checked Horizon's web site (until today): fog w/ respect to telemetry.

On the other hand several new receivers appeared, w/ a "T" in their names:
SRXL telemetry? No, original unidirectional SRXL for channel data Tx->Rx->FC. Does it work? Not really, only w/ workarounds in the corresponding FC. Why? E.g. because of incorrect byte sequence in a crc16 (checksum). Some other issues as well.

Aha.. and where is the bidirectional SRXL, a new kind of SPEKTRUM telemetry? There: SPM4649T. A small size single line receiver, SPEKTRUM calls it "Quad Race Receiver"..

Ok.. - all SPEKTRUM sensors speak I²C yet, so need a X-bus port. Of course these new receivers (except of the 4649T) have such a port. So let's test JLog with these receivers, connect it to the X-bus of them. No SRXL+, so we have to stay w/ X-bus for the moment..

Oops! What's that?! Does not work. Why?
A firmware bug in the receiver, what else.. Wrong port initialization, wrong handling in the service routine. ...and, of course, ... nobody were listening to me since 2011: no revised, useful scan by the bus master (Rx), than even faster starting and performed compared to that scan crap in the TM1000.
But the actual problem is that the master simply hangs the bus forever because it has seen an "artifact" from a slave powered up in parallel. Sigh.

Alternatives, workarounds? Yep:
- use of a working receiver like the AR7700 together w/ a TM1000
- to power up JLog (all types) before the "T" receiver (S32: about 10s)

...