I am starting this thread as a place to report issues and bugs and suggestions involving the JETI LUA scripting system and its implementation.

This is for reporting issues and bugs with respect to;

• JETI DC/DS Lua Programming API (or future Jeti documents)

• the LUA version specified in the API

• the Lua Standard Libraries specified in the API

• the additional custom libraries specified in the AP

Please do not:

• ask how to questions

• post user code issues unless they demonstrate a bug or issue in the above specification

Posting workarounds to LUA issues is also welcome.

When using the JSON functions there is loss of precision that severely impacts its usefulness

local function init()
  local tab = {} 
  tab.id = 1559602192
  tab.param = 2
  tab.label = "lat"
  
  print(tab.id, tab.param, tab.label)
  local jsn1 = json.encode(tab)
  print(jsn1)
  
  print(tab.id)
  print(tab.id + 0.1)
end

return {init=init, author="JWC", version="1.0", name="jsontest"}

produces this output;


Jeti LUA implementation uses 32bit numbers.
The ID value is fine while it is whole.
The ID looses precision when converted to 32bit float. This is expected.

The issues is that the CJSON implementation chosen by JETI, converts all numbers to float this causes a loss in precision, on encode/decoding typical items in the API like telemetry.

For example, its not possible to encode and decode the id of the telemetry sensor or any integer the more than 8 digits.

As a developer, i would expect, any method of serialization provided would be capable of encoding and then decoding number i can use in my scripts, in a lossless way. It seems to me the choice of CJSON or how its implemented in Jeti LUA currently does not provided this.

Script attached.

If you look at the DetectedTelem in the model files, Jeti manages to write out the same stuff without corrupting the large integers.
They are doing that with 32bit C not LUA.
Seems like Jeti should be wrapping their own JSON C code as a the LUA JSON library, and not use CJSON.

The is not a completely generic workaround to the issue, but currently works with the data structures i need to dump and load.
It should be adaptable to other data models.

In my case the data structure is the one returned by the API function system.getSensors(), which is an Array of sensors(key/value Tables)

I have written a LUA library to wrap the CJSON library.
I convert any number values in the Tables from number to string before using CJSON to encode.
I convert strings that should be numbers back after using CJSON to decode.

Encoding is simple.
To decode, you have to have knowledge of your data structure and convert specific strings back to numbers.

My LLJSON (loseless json) library includes a function that allows you to specify the KEYS of the VALUES that need conversion back to number.

Here is the LLJSON library;

local lljson =  {}
local numberkeys = {}

local function printVT(v)
  print(v .. " (" .. type(v) .. ")")
end

local function UnStringifyTable(t)
  for i,key in ipairs(numberkeys)
  do
    if(t[key]) then
      t[key] = tonumber(t[key])
    end 
  end
end

local function UnStringifyArrayOfTables(a)
  for i,t in ipairs(a)
  do
    UnStringifyTable(t)
  end
end

local function StringifyTable(t)
  for k,v in pairs(t)
  do
    if(type(v) == "number")then
      t[k] = tostring(v)
    end
  end
end

local function StringifyArrayOfTables(a)
  for i,t in ipairs(a)
  do
    StringifyTable(t)
  end
end

function lljson.encode(item)
   StringifyArrayOfTables(item)
   return json.encode(item)
end

function lljson.decode(encoded)
   local decoded = json.decode(encoded)
   UnStringifyArrayOfTables(decoded)
   return decoded
end

function lljson.setKeysWithNumberValues(keys)
   numberkeys = keys
end

return lljson

Here is a simple test app, with simplified "sensors";

local function init() 
  local myArray1 = {{id=1559602192, param=2, label="lat"},{id=1559602192, param=3, label="lat"}}
  
  -----------------------------------------------
  --comment out next two lines to use pure CJSON
  local json = require("lljson")
  json.setKeysWithNumberValues({"id", "param"})
  -----------------------------------------------
  
  local encoded = json.encode(myArray1)
  print(encoded)
  
  local myArray2 = json.decode(encoded)
  print(myArray2[1].id, type(myArray2[1].id))
end
  
return {init=init, author="JWC", version="1.0", name="lljtest"}

Add this to your app and LLJSON overrides the CJSON library.

  local json = require("lljson")
  json.setKeysWithNumberValues({"id", "param"})

You can make the same calls shown in the Jeti API doc.
In this example, key/value pairs in the sensor tables with keys (id and param) will encode/decode as they should!
You can comment out these two lines, and the test app will run on CJSON and give crap.

Its not prefect, but it will get you past some current json issues. For the purists, yes i know that the original sensor tables is changed. In my, case this fine. I write the JSON file and the app is done. I could clone the structure, then encode the "stringified it" the copy, leaving the original structure intact, but the peak mem usage would go up. Feel free to improve it for your apps.

Good job cravenjw, I will see how include this into QuarkEmu if you allow me, but this small extra lib take memory instead of your code.

No problem for DS/DC 24, I never reach memory limit, but for DS/DC 16 it's a real problem. My F5J Chrono App takes 21 Kb of LUA source code and can't be handle by DS/DC 16 version. This is why I only deliver lc compile file working with all 24 & 16 versions, less confusing for everybody.

The only way to preserve memory will be that Jeti use another C lib for JSON, there is bunch of libs in github ... may be a matter of licence ?

I have a complied version.

I took awhile to figure out how to compile the lib. To compile a (app/lib) combo;

You move the lib.lua file in the apps folder

Then use the dumper to compile to lib.lc

Then move lib.lc to the lib folder, and remove lib.lua

The new compiled app.lc, that uses the library will fail to find the lib.lua

But app.lua will run, as it finds the new lua.lc in the lib folder

Use the dumper again to recompile app.lua, to app.lc

The compiled app.lc will now work with the lib.lc in the lib folder, and total mem is miniminized.

Also, I use the lljson locally at the init scope, rather than local at the app scope, to minimize mem usage to when I am using the json functions, which in my case is at the startup to load config, before flight and the app really is live yet, or at the end to encode something after flight.

I'll update the attachments with the compiled versions.

Yes, you may use anything I post in this thread in your project.

Hello
Not sure if this is the correct place to ask this...

I'm modifying a LUA app that display multiple telemetry values in a single screen.
I retrieving the signal quality using the function system.getTxTelemetry. I'm displaying the Q and A1 and A2 RSSI values for each Rx (two 2.4 + 900).
The issue is that for A1/A2 RSSI, I get very different values from LUA versus the ones shown in the Transmitter. The ones in LUA range from almost zero to about 75 (very close to receivers). The ones in the transmitter show from about 3 to 9

When LUA shows close to zero (i'm moving out within my house looking to block the signal), the system sometimes warn me that is "switching to backup". This gives credibility to the low Q and RSSI captured via LUA.

The LUA values are two digits usually (e.g. RSSI = 72). I first though that the value shown in the transmitter was just the first digit (e.g. 72 is shown as either 7 or 8), but what I get suggest that is not the case.

Here is how I get the values in LUA:
local txTel

In the Loop function:
txTel = system.getTxTelemetry()

display Rx1 signal quality:
lcd.drawText(6,15,string.format("Rx1: Q=%d%%, A=%d/%d", txTel.rx1Percent, txTel.RSSI[1],txTel.RSSI[2]), FONT_MINI)

Thoughts?

Thanks

Originally Posted by Edgar Perez

Hello
Not sure if this is the correct place to ask this...

I'm modifying a LUA app that display multiple telemetry values in a single screen.
I retrieving the signal quality using the function system.getTxTelemetry. I'm displaying the Q and A1 and A2 RSSI values for each Rx (two 2.4 + 900).
The issue is that for A1/A2 RSSI, I get very different values from LUA versus the ones shown in the Transmitter. The ones in LUA range from almost zero to about 75 (very close to receivers). The ones in the transmitter show from about 3 to 9

When LUA shows close to zero (i'm moving out within my house looking to block the signal), the system sometimes warn me that is "switching to backup". This gives credibility to the low Q and RSSI captured via LUA.

The LUA values are two digits usually (e.g. RSSI = 72). I first though that the value shown in the transmitter was just the first digit (e.g. 72 is shown as either 7 or 8), but what I get suggest that is not the case.

Here is how I get the values in LUA:
local txTel

In the Loop function:
txTel = system.getTxTelemetry()

display Rx1 signal quality:
lcd.drawText(6,15,string.format("Rx1: Q=%d%%, A=%d/%d", txTel.rx1Percent, txTel.RSSI[1],txTel.RSSI[2]), FONT_MINI)

Thoughts?

Thanks

I think I found the answer... see https://www.rcgroups.com/forums/show...ostcount=27649

Hi, Anybody solve or pass advise upon the error I am getting after installing the Momentary to Latching Lua v1.8. Have 2 snapshots showing error and other version info. Be very grateful if somebody could pick this up and help. Thank you /Alan