Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple frames in an only transmision. #293

Open
flopyplus opened this issue Oct 22, 2020 · 9 comments
Open

Multiple frames in an only transmision. #293

flopyplus opened this issue Oct 22, 2020 · 9 comments

Comments

@flopyplus
Copy link

I observed that other tnc´s ehen digipeat various sequential frames (i.e. telemetry) without time for transmitit each one, when the channel is clear, digipeat all the pendings frames in a only one transmit without release the ptt. Direwolf transmit one by one separately with the tx delay.... tx tail... etc. Is possible change it and repeat in this cases with only one transmision?

@wb2osz
Copy link
Owner

wb2osz commented Oct 23, 2020

I agonized over that question. Is it more appropriate to bundle multiple digipeated APRS frames in a single transmission or send each of them separately?

It's trivial to change in xmit.c:

              case FLAVOR_APRS_DIGI:
                xmit_ax25_frames (chan, prio, pp, 1);       /* 1 means don't bundle */
                break;

but would it be appropriate? I need to ponder this and see if I come up with a different answer this time.

@flopyplus
Copy link
Author

Obviusly is more efective and is the common work of any tnc, digipeat in one transmition without release the ptt all the frames accumulated for not oportunity in a occuped channel.

@ggramaize
Copy link

ggramaize commented Oct 23, 2020

I agonized over that question. Is it more appropriate to bundle multiple digipeated APRS frames in a single transmission or send each of them separately?

[...]

but would it be appropriate? I need to ponder this and see if I come up with a different answer this time.

Frame aggregation is definitely a way to gain goodput, especially at higher speeds, because of the significant turnaround time.
IMO, your "don't bundle" flag should be interpreted as a "flush buffer" command.
Finding an optimal (and non abusive) buffer management strategy looks like the main challenge.

@flopyplus
Copy link
Author

Aparently in windows with 1.5 works fine. Other question is if affect that direwolf receive in most cases the propious transmisions in linux. I think that when direwolf is transmiting, the rx is better turning off

@dranch
Copy link
Collaborator

dranch commented Oct 23, 2020

It's strange to me that Windows has a different behavior. Anyway, maybe this can be an advanced preference in direwolf.conf?

@flopyplus
Copy link
Author

Here an example of th configuration of a 3in1 tnc. By default the transmisions are in burst and not separatelyIMG_20201023_221945

@dranch
Copy link
Collaborator

dranch commented Oct 23, 2020

Got it and looks like you have a WX3in1plus (page 17) microsat.com.pl/manual_download.php?file=wx3in1plus_v141_manual_english.pdf .

I've been doing a little research here and it seems there are several pros/cons to offering this kind of functionality on an APRS channel. Try searching for "WB4APR APRS multiple packet "bundling"" and you can see a lot of these discussions. One critical thing to consider with those various discussions is the bundling pros/cons of connected packet vs. unconnected packet (APRS).

@flopyplus
Copy link
Author

Really all are confused. I don´t how work direwolf, because in a hardware works in a mode, in other harware works in other mode, in windows aparently works in burst, in linux is separately and really slow..... I don´t undestand nothing! But the nest solution i think that the mode to be selectable that in the others tnc´s, or a best documentation about that.

@ab5hl
Copy link

ab5hl commented Jan 1, 2021

I don't know if it is related, but when testing a setup with a Raspberry PI and let it off for a day or two, or a couple of hours, after power up, goes on multiple frames.

Maybe a time/date related "feature" or bug?

Using Raspberry PI 3B+ or 4. ( no Real Time Clock , using NTP to set date/time automatically )

Starting Direwolf using cron, * * * * * /home/pi/dw-start.sh >/dev/null 2>&1

I was thinking that when direwolf starts, the Raspberry has the time of the last time was on, then after some time NTP corrects the time Direwolf tries to catch up sending PBEACON ????

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants