mwp should support Taranis s.port telemetry

[stronnag]

If you use a Taranis radio you may be interested to know that a collaborative effort is taking place to understand and use the telemetry that is available from a Taranis TX serial port. See https://github.com/opentx/opentx/wiki/Taranis-I-O-ports for details on how to use the serial port in your radio.

The intention is that S.port telemetry would be usable in mwp and ezgui. Currently, pretty much all we know about decoding this data can be seen the mwptools/samples/frsky directory. Frsky's proprietary (requiring an NDA) attitude is not helpful in this regard.

If you interested in using s.port telemetry source in mwp or one of the other iNav ground stations and you have a Taranis TX, you can help by providing sample data, preferable a captured data file accompanied by a blackbox log.

Suitable tools to capture the log data include the ttycap tool included with mwptools, mwptools/samples/ttycap, or putty on Windows.

Please either link your data into the issue, or PM @stronnag if you want the data to be treated as private.

[stronnag]

Anyone? In particular those who though this was needed?

[markandkymward]

Have you seen this? https://github.com/lvale/MavLink_FrSkySPort

[stronnag]

As no one who thought this was important has shown any interest in providing sample data, this non-issue is closed.

[stronnag]

Reopening as I have some useful data and a willing beta tester.

[stronnag]

In the development branch, the `samples/frsky/frsky' tool can now read the useful data from @wilco1967's log. This looks like it will be good enough to support real-time flight visualisation.

[stronnag]

updated the TX serial port link in the first post to work again.

[stronnag]

Just pushing RSSI and VBAT into the UI (however, all the data is decoded by my local mwp, just not visualised). The data is being sent into mwp serial subsystem by a replay tool from the sample data.

[stronnag]

This is now getting to the stage where a flight log is necessary to progress:

• Preferably accompanied by a blackbox log;
• Multiple modes (acro, manual, cruise, ph, WP) if possible.

Note that the sample I have currently:

• Does not contain attitude (pitch / roll) data
• Does not contain HDOP (and the iNav approximation appears to be broken / only reports 'bad' (5.5))

Locations obfuscated to protect the innocent.

[wilco1967]

sent you a PM in RCGroups with logfiles

• acro, manual, cruise, ph, WP

Acro, check, during take-off) manual, check (during landing) cruise, check (95% of the flight... ;-) PH, not in this flight.... will make one tomorrow WP, not in this flight... will do tomorrow. RTH, included FS/RTH, included. (mostly intentionally, by using 10mW only for the first 10 km...)

• Does not contain attitude (pitch / roll) data It does now, I can see it in the Taranis log (which is the same S-port telemetry). Perhaps yesterday, it didn't move at all. AccX / Y / Z

• Does not contain HDOP (and the iNav approximation appears to be broken / only reports 'bad' (5.5)) guess it's included in the Tmp2 field (at least, in OpenTx)

[stronnag]

Using the smartport branch

There is now a smartport branch that implements smartport telemetry parsing. For now, you need to build the smartport branch. e.g:

$ cd Projects/mwptools
$ git pull
remote: Enumerating objects: 45, done.
remote: Counting objects: 100% (45/45), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 31 (delta 20), reused 0 (delta 0)
Unpacking objects: 100% (31/31), done.
From eeyore:/t/tmp/mwptools
   802b09e..06022db  development -> origin/development
 * [new branch]      smartport   -> origin/smartport
Updating 802b09e..06022db
Fast-forward
 mwp/mwpid.h                  |   2 +-
 samples/flash.sh             |   3 +
 samples/flashdl/flashdl.vala |   7 +-
 samples/frsky/frsky.vala     | 169 +++++++++++++++++++++++++++++++++++--------
 4 files changed, 148 insertions(+), 33 deletions(-)
$
$ git checkout smartport
Branch 'smartport' set up to track remote branch 'smartport' from 'origin'.
Switched to a new branch 'smartport'
$ # now make, etc.

Note: If you don't see the new branch from git pull, you need to enable your local repository for all origin branches; this is described in the dependency documentation e.g. docs/ubuntu-deps.txt (but it's the same for everyone).

Once, built, you can either run mwp from the mwp directory, or sudo make install to install it.

At the moment (and this may change later once there is more experience of how this function might be used), it is necessary to define the smartport device on the command line, or add it to ~/.config/mwp/cmdopts, e.g. (running from the build directory):

$ mwp/mwp --smartport tcp://localhost:43210  --force-type 8

The device after --smartport can be any mwp supported device name; in this example I'm using a TCP/IP replay tool (more below) and because I don't first connect using MSP, I need to device the model type (8 == flying wing). For a bluetooth device (maybe connected to the Taranis battery compartment serial port), and after installation:

$ mwp --smartport 00:14:03:11:35:16
# or
$ mwp --smartport /dev/rfcomm42

If you always use the same device for smartport, you can add the command option to ~/.config/mwp/cmdopts; in this case you can launch an installed mwp from a desktop icon.

 cat ~/.config/mwp/cmdopts 
# Default options for mwp
--rings 50,20
#--voice-command "spd-say -t female2 -e"
--wayland
#--debug-flags=2
--dont-maximise
#-S 8192
#--voice-command "ftest file:///home/jrh/Projects/flite/cmu_us_clb.flitevox"
--smartport 00:14:03:11:35:16

When you invoke mwp with --smartport, you will see a new device *SMARTPORT* in the serial device drop down. In order to use it, you must first close (disconnect) any MSP device, and open (Connect) to the *SMARTPORT* device.mwp is now taking telemetry from your Taranis serial port.

Simulator / replay tool

In the samples/frsky directory, there is a replay tool that will replay captured smartport logs. By default this tool listens on a localhost TCP socket, port 43210; this is accessed in mwp by setting the smartport serial device as --smartport tcp://localhost:43210. Before you connect in mwp. you must have started the replay tool:

$ cd mwptools/samples/frsky
# use the replay tool, we can connect / disconnect from mwp as we wish ...
$ ./sport_tcp_replay.rb s-port-short.log 
++ New session ::1:39458
-- Close session
++ New session ::1:39576
-- Close session

In the example, s-port-short.log was the smartport log file (thanks @wilco1967). The file plays in approximately real time; there are options to change the rate and port:

$ ./sport_tcp_replay.rb  --help
Usage: sport_tcp_replay.rb [options] file
    -p, --port PORT                  43210
    -d, --delay SECS                 0.00167
    -?, --help                       Show this message

ToDo

This function is not yet complete:

• Better (auto) switching to s-port telemetry
• Verify that AH is working correctly
• Writing to mwp (JSON) logs is incomplete
• Validate RSSI scaling
• Not all "docklets" are populated (see images for those that definitely are).
• Fix bugs from live (vice replay) usage

Examples

Same flight, blackbox and smartport visualisation (note the images are not taken at exactly the same time, so some items will be different).

[stronnag]

In theory, 17a241f should fix the crashes with Bluetooth. (usual git pull ; git checkout smartport ; make && sudo make install. If you're already on smartport then the checkout is harmless and a no-op).

And there's now a replay over a physical device tool, so I can have /dev/ttyUSB0 on the serial side of a BT device, and:

# terminal 1
./sport_dev_replay.rb -s /dev/ttyUSB0 s-port.log 
Note: sending starts immediately, hope your consumer is ready
# terminal 2
mwp --smartport 00:14:03:11:35:16 -t 8
# or
mwp --smartport /dev/rfcomm1  -t 8
## same thing for that BT module ...

[stronnag]

Note that smartport can generate a lot of points, which the geo library used by mwp will store in memory. You can limit the number of points stored (but the line trail is still plotted) with mwp's -S npoints option

mwp -S 4096 # only keep last 4096 points. 

You can make this permanent by putting the -S setting into ~/.config/mwp/cmdopts, thusly:

$ cat ~/.config/mwp/cmdopts 
# Default options for mwp, leading # is a comment 
--rings 50,20
# only keep 4096 points (tune for your free memory)
-S 4096
--smartport 00:14:03:11:35:16

[stronnag]

Limiting the number of points is probably not enough if you have < 2GB of memory in your system / VM. Reducing the frequency of plotting also helps, so a combination of -S and -M:

mwp -S 1024 -M 8 # keep 1024 points, plot every 8th GPS report.

As we're plotting fewer points, we can keep fewer as well.

But it doesn't help that much. libchamplain is a memory hog. I can also modulo (-M) the line points; makes the update graphically a bit ugly, but saves memory.

8ca9a2b implements this behaviour.

[wilco1967]

Hi Stronnag,

Flew 2 batteries today, with S-port going to MWP.... S-port taken from the inside battery bay serial port, via inverter & bluetooth to MWP.

In one word: Excellent !!!

with the -S and -M options, it never froze.

I've uploaded the MWP logfiles, the BB logfiles (including yesterdays), as well as the raw S-port logfiles (openlogger) in the shared directory.

Only one thing strange.... Distance reported on MWP seemed to be correct during most of the time, however, near the end of the 2nd flight, it looked like MWP thought the home position had changed somehow, and it started to show distance relative to that position, which was ofcourse different from the actual distance as reported by OpenTx. / iNav (they got it right).

Seems like MWP does its own distance calculation,.... That's great if no distance is provided by the telemetry. But in S-port, distance is available as '0420' parameter. If possible, perhaps show the distance as reported by telemetry, when available. And only use calculated distance by MWP, when no distance transmitted.

Also, is mAh used available somewhere ? It's in the telemtry stream as 'fuel'... would be nice to show in the battery widget together with voltage.

Didn't notice any other 'problem'...

Great work !, thanks an awful lot.

BTW: Should I make some 'advertizing' in various groups, so others can try out MWP... I'm pretty sure many of them never heard of MWP, but thet will like being able to track the flight on the map.

Or perhaps do you want to wait a little, and complete your 'to-do''s first ? You may get a lot of questions like it is now... (not everyone is confortable to go into the Terminal window, and its likely to cause some confusion).

Again, thanks a lot.... working great !

Next couple of days, I'll be writing up a little Wiki 'procedure' how to build an inverter, power regulator, connect the BT module, etc. , and extend the current Wiki on installing on windows machines.... may take a few days.... need to go work as well.... Guess it will be needed, and that's something I can do to help this project....

[stronnag]

Thanks for testing.

• Distance. I take distance from home from the sport but reuse mwp's calculation (as for LTM). I'll see what happens from your log, and maybe use the sport value (it's easier not to ...). The way sport (doesn't) actually report the home position makes it a bit more interesting as well.
• Current. To do. I'm parsing and ignoring at the moment.

So my next job is to merge this into development (so the smartport branch can go). It's also been useful in that it's driven some improvements in the I/O parsing regardless of anything else.

It's probably not worth publicising too widely until it reaches master, which is probably a week or two away.

• [ ] Better (auto) switching to s-port telemetry
• [x] Verify that AH is working correctly
• [x] Writing to mwp (JSON) logs is incomplete
• [ ] Validate RSSI scaling
• [ ] Not all "docklets" are populated
• [x] Incorporate current
• [x] review distance to home strategy
• [ ] consider auto -S, -M strategy based on free memory.

[stronnag]

Apropos you comment about the changed home. The reason that happened is because the smartport telemetry told mwp that home had changed, here's the (not yet published to github output):

2019-02-17T19:20:45+0000 SPORT_DEV_FR_ID_HOME_DIST 4763m (mwp: 4764, diff: 1)
2019-02-17T19:20:45+0000 SPORT: Change Home: set new home position 51.999870 6.692298
2019-02-17T19:20:45+0000 Alert: beep-sound.ogg
2019-02-17T19:20:45+0000 Established home has jumped 4753.9m [51.999870 6.692298 (ex 51.957130 6.689233)]2019-02-17T19:20:45+0000 Set home 51.999870 6.692298 (SPort true)
2019-02-17T19:20:45+0000 SPORT_DEV_FR_ID_HOME_DIST 4743m (mwp: 17, diff: -4726)

So you'll see prior to mwp seeing smartport T2_ID (0x0410) with thousands digit 4 set, the difference is small (typically < 20m at 6000m); from what I know about mwp's geodetic rigour compared to iNav's, I know which I'd trust).

Smartport tells me Home has changed, by switch BOXHOMERESET.

inav/src/main/telemetry/frsky.c :

   if (ARMING_FLAG(ARMED) && IS_RC_MODE_ACTIVE(BOXHOMERESET) && !FLIGHT_MODE(NAV_RTH_MODE) && !FLIGHT_MODE(NAV_WP_MODE))
        tmpi += 4000;

What I am to do? Ignore it ??? What else do I then ignore ??

[stronnag]

Perhaps I'll ignore smartport change of home if it occurs more than 100m from original home (I expect it's reliable within short ranges and it's a pretty unusual use case for normal people).

[stronnag]

07b56c6

• ignore potentially bogus change of home
• log mwp v. smartport home distances differences exceeding 10% of range

[stronnag]

Amps:

[stronnag]

1713ed1 adds more logging (including the received RSSI (raw)), with correct timestamps:) If I can have a set of logs (smartport, mwp-json, blackbox) it should be possible to determine the correct RSSI scaling.

[wilco1967]

Could this reported change in home position be caused by corrupted packets ? Or is it something by iNav ?

I remember seeing something similar before when using LTM... Can LTM actually report change in home position, or is this something different ?

Anyway, looks like great progress.... However won't have time to test anytime soon.... Need to work....

[stronnag]

My guess it goes something like this:

• There's a momentary glitch on the RX that asserts 'HOMERESET'
• iNav core ignores it
  • It requires multiple cycles before it believes the RX
  • It did not reset the home distance
• The iNav smartport telemetry code is less smart; it just sees 'HOMERESET' and asserts it in the telemetry stream

I can think of no good reason to change home BVLOS; so it will be ignored above a certain range (100m is probably too close, perhaps 500m).

LTM is more sophisticated; it reports the actual home that is being used by iNav. It also reports a lot more 'state'; it's altogether a better solution, albeit not as convenient for Taranis users.

No hurry on the more test data; rssi scaling is the last remaining 'unknown'.

[stronnag]

6f34c49 mwp's logs generated from smartport can now be replayed in mwp

[wilco1967]

• There's a momentary glitch on the RX that asserts 'HOMERESET'
• iNav core ignores it

To do a home reset via RX, from my understanding, I should have configured that function in the mode's tab in iNav, which I didn't. iNav never-ever has reset its home position in the air in my flying experience, and it had plenty of flying time, often to the limit (and beyond) of radio range, so it had plenty of opportunity.

But why would someone want to change the home position at all ?

I was more thinking about a corrupted packet of S-port telemetry being decoded as home reset somehow.

I sometimes see very strange values for a second or so, also on Taranis screen In the Taranis logfile from yesterday (just uploaded to the shared drive), I see Hdg in the millions deg for a few seconds, GSpd of over 1900 km/h, or VFas of about 2,7 million volt..... I should see some damage with that kind of voltage... ;-)

These are just spikes, and I attributed them to corrupted data. Perhaps some bits inverting, and still passing an error check.

What (if any) kind of error checking is there on S-port data ?. Guess not much. Just a basic parity check would allow occasional errors to slip through.

If it is iNav giving false information, perhaps we should raise an iNav issue on github ?

[stronnag]

Just because you've not configured it does not mean the RX cannot get a glitched packet. There is a checksum on the sport data, so its unlikely to be a corrupt sport packet (imho).

[stronnag]

You should also be aware that smartport telemetry is just crap compared to (e.g LTM). Here's the stats from the 2019-02-17 flight 2:

total 256671, good 124329, bad 1, short 132341

bad means the CRC failed (so it gets dropped), short means that the packet was not the correct size (often seeing 2 byte packets, should be 10). Just crap.

[wilco1967]

well.... considering I flew quite a lot behind obstacles, where telemetry was lacking, I still find that pretty good... ;-) But looking at the live S-port stream, using the laptop via a serial adapter, on the bench, I see a lot of messages which are only 2 byte... they seem empty. Guess MWP counts them as 'short'...

Whatever.... plenty of good packets arrive, so no problem...

But if it is not S-port being corrupted, and it still says to change the home position, this information must then have come from iNav itself.... isn't it ? iNav didn't actually change the home position, but somehow said it did over S-port ? perhaps we should raise that as an iNav issue to verify ?

Still find it strange, if the CRC is so good, why the Taranis also sees some random values ? Whatever.... No problem to have an occasional wrong value, as long as it doesn't mess with actual flying (which seems just fine).

BTW, I've been experimenting a little with RSSI.... The RSSI as reported by S-port / MWP is correct. MWP is reporting the same value as iNav (OSD) value

Problem seems to be channel 16 output of the RSSI of the R9MM receiver which iNav uses as its source.... The channel 16 value doesn't match the value shown on Taranis screen. (checked both channel raw counts, in uS, and indicated RSSI. (iNav default RSSI_MIN = 0, RSSI_MAX =100).

When I use the 'old fashioned' way to sent the RSSI from the Taranis, back via the mixer via a 'normal' RC channel (I choose CH15), and configure CH15 as the RSSI source in iNav (rather then CH16), it will show the same on OSD, and the same value also shows on MWP.... All agree.

So the MWP / S-port RSSI implementation is correct.

Some strange ranging is done in the R9M when being sent via CH16... We'll assume the value sent down directly from RX to the Tx (not via iNav) of being the correct one....

Guess we'll sooner or later find out, what Frsky is doing with the Ch16 output scaling. (perhaps some logarithmic scaling, or whatever...).

Thanks !

[stronnag]

Whatever, indeed, less than 50% of the packets are useful.

If you wish to raise an iNav issue over the home reset, the offending packet (sole instance of home reset) is at byte offset 848429 in your 2019-02-17 log 2.

As RSSI appears less of an issue, I'll write up the configuration on the wiki and merge development into master and be done with it. If nothing else, it has revealed some bugs in mwp's serial parser which are now fixed.

[stronnag]

and you can now log the smartport data using mwp's raw log facility (mwp -r)

[wilco1967]

I've wrote up a little Wiki on building the Bluetooth dongle. https://github.com/stronnag/mwptools/wiki/Building-a-bluetooth-adapter-for-Taranis-S-port-telemetry-for-MWP Let me know if you seen any errors....

Thanks !

[stronnag]

Thank you; linked in the main smartport article and the front page sidebar.

[stronnag]

Current and power usage is displayed too. For smartport only (not MSP or LTM), it is necessary to set 'fuel' units as the user can configure these on the FC:

$ gsettings range org.mwptools.planner smartport-fuel-unit 
enum
'none'
'pct'
'mAh'
'mWh'
gsettings set org.mwptools.planner smartport-fuel-unit 'mAh'

(or use the GUI dconf-editor if you prefer).

Note: Amps / power is just in development for now, 7d2c455

[stronnag]

fuel stuff seem stable now, merged into master. I will probably close this soon, unless there are some new revelations on e.g. RSSI handling (which is probably good enough).

[wilco1967]

Rssi works just fine.... Problem is R9M ch16 output... Not a MWP problem. On current, perhaps you could add one extra digit.... x.x amps, rather then X amps. Thanks!

[wilco1967]

Hi Stronnag,

not sure if this is related to S-port, or something more general, but I have a strange issue affecting mwp log replay.

I've uploaded a logfile to that same shared directory, mwp_2019-02-24_144208.log When replaying, it shows the map near Sao Tomé, off the coast of Africa, while in reality, I was near Markelo, Netherlands.

GPS coordinates are 52.22N , 6.55E... Shown correctly in the MWP numerical display. However mwp showed the map at 0.00N, 6.55E

This happened on the 2nd flight. First showed alright. I didn't re-start mwp before the 2nd flight. During the 2nd flight, at first, it seemed alright. the first few minutes were logged correctly (mwp_2019-02-24_142227.log).

When I noticed it stopped work properly, I couldn't get it correct. Only after I stopped mwp, and re-started, the realtime map showed correct again. (plane was still flying on it's own).

However, the logfile shows faulty map positions (though correct numerical GPS data) when I re-play the mwp log file. other mwp (and bb) logfiles show correct.

Also uploaded the corresponding blackbox log... I didn't record the raw S-port data

I did loose telemetry a few times, when flying beyond obstacles a few times. That may have influenced things.

This was last Sunday mwp version.

[stronnag]

It is an artefact of corruption in the telemetry, exacerbated by restarting the log when telemetry was lost / corrupt.

mwp tries to mitigate by corrupt telemetry by:

• Not allowing large jumps in position; and
• Being more trusting of location data at the start of the log.

The second log fragment fails both of these by

• Having the corrupt locations at the start of the log
• and then jumping a large distance to your location.

If you simply join the logs together (the grep is necessary otherwise mwp would be confused by the second init stanza in the log, but I'll fix that so one can just cat logs together):

(cat mwp_2019-02-24_142227.log ; grep -v init mwp_2019-02-24_144208.log) > combined.log

If I replay this combined log, mwp ignores the corrupt packets; in the 'debug' log (~/mwp_stderr_2019-03-01.txt, or console if run the shell):

2019-03-02T11:26:35+0000 Ignore bogus 0.000000 6.642253 (52.236930 6.650690)
2019-03-02T11:26:35+0000 Ignore bogus 0.000000 6.642018 (52.236930 6.650690)
2019-03-02T11:26:35+0000 Ignore bogus 0.000000 6.641783 (52.236930 6.650690)

And one can see that there are quite large areas of no telemetry (along the river in particular):

The join is where the rivers converge / split:

The arrow indicates the end of first log, quite a bit of drop out, and no valid coverage in the second log for a considerable distance.

So I don;t think there's much mwp can do in the face of missing / corrupt data, other than:

• Allow log segments to be contatenated together
• Don't include bogus jumps in distance calculation

And the reason why you don't see the 0,0.6 locations in the flight view widget is that they are momentary and there are only 3 of them.

[stronnag]

d5cab2c (development) addresses concatenating logs for replay and ignoring bogus jumps in distance calculations.

cat mwp_2019-02-24_142227.log mwp_2019-02-24_144208.log > concatonated.log

The speed is also corrupt from the telemetry (nothing I can do about that), and it looks like I'm not transcribing the current draw correctly from S-port into mwp logs ... next job.

[stronnag]

current values should now be stored correctly in mwp logs (d45cdc8, development).

and, btw, it's likely directly processing s-port would have performed at least as badly as the logged data, as there are currently fewer sanity checks there ... looks like the next job. And you can transparently log raw s-port data with mwp --raw-log (fyi).

[stronnag]

added sanity checks to s-port processing 44638c4 (development branch)

[stronnag]

I did actually know that I'd forgotten to include s-port telemetry in mwp's data timeout monitoring and reporting scheme; only I'd forgotten that I'd forgotten. Now I've remembered.

So now if s-port fails to provide data for > 5s, you will be informed (audibly and visually).

Had this been in-place at the time, you would have found it got quite noisy around 2019-02-24 14:42. ed54709 (development branch)

[stronnag]

For completeness, when mwp is replaying a mwp log file, to avoid annoying the user with long periods of inactivity, it skips over "no-data" gaps of more than 10 seconds, and writes the missing time to the console log / mwp_stderr_YYYY-DD-MM.txt)

So from replaying the concatenated log, we see in the console log:

2019-03-03T09:20:10+0000 Set home 52.214522 6.549532 (RAW GPS true)
...
2019-03-03T09:20:37+0000 replay sleeping for 10.6 s
...
2019-03-03T09:26:41+0000 replay sleeping for 690.1 s
2019-03-03T09:27:04+0000 replay sleeping for 66.7 s
2019-03-03T09:27:04+0000 Ignore bogus 0.000000 6.642253
2019-03-03T09:27:05+0000 Ignore bogus 0.000000 6.642018
2019-03-03T09:27:05+0000 Ignore bogus 0.000000 6.641783
2019-03-03T09:27:26+0000 replay sleeping for 515.8 s

So it's pretty obvious from this "replay sleeping" (and the difference between the telemetry log and blackbox) that you lost telemetry for significant parts of the flight. mwp will now warn you about this during the flight.

[wilco1967]

sounds good.... I won't have time the next couple of weeks to try it.... Will be out of the country for a few weeks and will be end of march before I can have another test. Thanks !

[wx4cb]

nice... Only just found out about this project. let me know if you need any help. also, do you know if the telemetry data that comes back over crossfire is available at the serial port too? I'm having issues with the bluetooth and would prefer a hard wire connection :D

[stronnag]

All the smartport stuff is now committed to master, and thanks to @wilco1967 's logs, I think it's pretty much done.

As far as crossfire is concerned, @markandkymward has had success using MAVLink over CSFR, including forwarding MAVlink to a ghettostation antenna tracker (see #35)

[wilco1967]

Hi Stronnag

quick question: is there a trick to replay raw S-port data stored in a file back in MWP ?

[stronnag]

There is a method, in this order:

In one terminal

cd mwptools/samples/frsky
./sport_tcp_replay.rb <path-to-smartport-logged-data-file>

In another terminal

mwp -t 8  --smartport=tcp://localhost:43210

where -t 8 sets the vehicle type (icon), 8 == flying wing and by default the replay uses tcp port 43210.

You can alter the port and replay speed, see

$ ./sport_tcp_replay.rb --help
Usage: sport_tcp_replay.rb [options] file
    -p, --port PORT                  43210
    -d, --delay SECS
    -?, --help                       Show this message

The default delay (0.00167s) plays your logs in about real time; you speed them up (or slow them down) using the delay parameter.

Note also that if log smartport raw data via mwp (mwp --raw-log, which is not the case for the logs you provided to me), then the inter-packet delay is stored in the log, and the replay script delay parameter is a multiplier to the stored inter-packet delay (then the default is 1.0, meaning 'as recorded').

[wilco1967]

yes, works !

Thanks a lot !

[stronnag]

I don't think we have anything more to add to this, so I'm closing the issue. please reopen if new information emerges.