START HERE |
|
Register | FAQ | PM | Events | Groups | Blogs | Calendar | Mark Forums Read |
Unregistered
|
JLog - The JIVE logging stamp JLog - The JIVE logging stamp - Official English Support Forum |
|
LinkBack | Thread Tools | Display Modes |
04-16-2016, 03:58 PM | #1 (permalink) |
Registered Users
|
JLog 2.6 w/Graupner
I've got my JLog 2.6 working with my Kosmik and MZ-24 after quite a bit of fiddling.
Is there a way to change the telemetry view on the home telemetry page(the page with gauges on it for Graupner's own telemetry? Or do I have to go to Function-Telemetry-Data view? Thanks |
Sponsored Links | |||
Advertisement |
|
04-16-2016, 04:28 PM | #2 (permalink) |
Registered Users
Join Date: Feb 2008
|
No, those displays are fix, defined in the terminal (transmitter).
JLog w/ "JLog" firmware supports two of the 5 HoTT sensors, GAM (w/ fuel gauge) and ESC. (JLog as HTI (Herkules Telemetry Interface) as well as S32 (aka JLog3) provides all 5 types of sensor (even in parallel), only GAM/EAM/ESC make sense with an ESC as virtual sensor to JLog.) In text mode a sensor (JLog) is free in arrangement of alphanumeric displays. JLog2.x, regardless of the supported pseudographic sensor display (GAM, ESC), provides two textual displays, operational one and with min/max values.
__________________
Tom (j-log.eu) |
07-02-2017, 05:32 PM | #3 (permalink) |
Registered Users
Thread Starter
|
Sometimes I am able to get my telemetry to come up with voice prompts other times it will not come up with voice prompts. Why? It really sucks to get to the telemetry screen on the Graupner to view data.
|
07-02-2017, 06:09 PM | #4 (permalink) |
Registered Users
Join Date: Feb 2008
|
Hmm.. A sensor has no influence on it. It's just up to the transmitter to speak corresponding to defined alarm codes. I know, sometimes that thing screws up a bit..
Same with values speaking. I wouldn't use that but if you like such a chatterbox..
__________________
Tom (j-log.eu) |
07-11-2017, 06:29 PM | #5 (permalink) | |
Registered Users
Join Date: Mar 2013
Location: Cleveland, Ohio
|
Quote:
In the sensors and data view or under the telemetry menus you can simply turn on /off the telemetry you wish to hear. I only followed the actual capacity used while flying and never looked at the mz24 display. I the S32 config software you can set your alarms for capacity and voltage, etc... the Graupner will us the voice output to read the alarms back when those thresholds are met in the S32. I thought the S32 interfaced rather well with the Graupner. Little learning curve at first, but intergrated well after reviewing the help files and HF.
__________________
Logo 600, Soxos Strike 7 Spirit GTR, Spirit2 RS, Jeti DS12 |
|
07-14-2017, 06:12 AM | #6 (permalink) |
Registered Users
Join Date: Feb 2008
|
Hi Ham brother! Thanks for helping!
How it works: During about 10 seconds after powerup of the receiver or after the transmitter has (re-)appeared to the receiver - a sensor scan is performed by the Rx on it's telemetry interface. Five sensor types (type IDs) are asked if anyone there. JLog as (potential) multi-sensor is responding on this addressing (sensor type query), other sensors on the telemetry 1-wire interface of the Rx as well. Afterwards, scan has ended, only sensors (types) will be polled which responded during the scan. For each sensor type only one sensor is allowed to exist and respond on the telemetry 1-wire! Above we're first speaking about binary sensor data packets with pseudo-graphical presentation in transmitter. (upto 5 +1(Rx) telemetry main screens selectable in transmitter). Each binary packet contains also data - what is not displayed in the main screen of a sensor (type) than in sub displays related to a main screen - highlighting of items in a main screen (when an element supports that, - only few do) - alarm codes - often also information which is nowhere displayed in transmitter.. Still about the binary data packet of a sensor (type): The transmitter (model, firmware release) decides how to handle received data... Some sub displays are shared by different sensor types. A sub display may correspond to more than one sensor (main screen). ...and design flaws... Some of those secondary displays mix different data from more than one sensor. Alarm codes are sensor-globally defined, so apply to all sensor types. The pseudo-TTS (pre-recorded PCM streams) is mapped to alarm codes, also language-related, of course. Sensor type "ESC" has a flaw: Does not know about all relevant alarm codes (some missing mappings to "tts"). Value speaking is just and only a configurable feature of the transmitter. It relies on items in these 5 types of binary packets only, of course. The little special function "vario" (beep-beep) is based on meters per second provided by all sensor types except of "ESC". A sensor should not use these data items (m/s, m/3s, m/10s) if there is also a real VARIO on the 1-wire bus - because inside of the transmitter is only one m/s used for the audible vario, perhaps filled by other sensors too. In addition each of the 5 sensor types can be polled under a 2nd address for textual data. The transmitter triggers the Rx to change to poll these addresses instead when you use the corresponding menu. You select the sensor (type) from which you want to read the textual output: 8 lines of 21 characters each, ASCII, possibility to position inversing (white-on-black). A sensor displays what it wants to, and on as many pages it needs/likes to use. The sensor receives also four key codes (up/down, left/right), so there is a way for interactively communicating to a sensor. (The number of textual pages used by S32 (JLog3) is configuration-selective, setup by S32terminal.) During the time of displaying a sensor textually, no binary data is queried from sensors. Therefore "tts" of selected data items is stopped in text mode. Textual sensor data contains also a part for current active alarms (codes), thus audible alarms can show up in text mode as well. Update rates: - binary packets: every 200ms the next sensor found during scan is polled, - so upto 1s a round for all five sensor types - textual packet: every 800ms the selected sensor (the sensor-interactively selected current page) You see, most functionality is matter of the transmitter. The receiver is a "helper", queries sensors on its telemetry interface (simple 1-wire async-serial 19k2 Baud), assembles packets for downlink to transmitter (smaller than those received from sensors). A "scan" is just a standard round robin query. Afterwards only sensors (type-addressees) having responded will be polled furthermore - to save the time (200ms each).
__________________
Tom (j-log.eu) Last edited by dl7uae; 07-14-2017 at 08:05 AM.. |
Thread Tools | |
Display Modes | |
|
|