Time too long between end of call sign and start of long dash sequence

[tomnd2t]

At K6TD today I listened to the IBPV2 prototype transmit.. It seems to me (by ear -- no measurement made) that the time between the end of the call sign and the beginning of the first long dash is greater than in the IBPV1 beacons on the air.

[tomnd2t]

There are IBP1 sound samples on http://www.ncdxf.org/beacon/beaconschedule.html. Long call or short, the time is constant between the end of the call and the start of the first long dash. Listen, for example, to w6wx (weight = 52) and vk6rbp (weight = 74).

Callsign Weight Time (12wpm) Time (16wpm) Time (20wpm) Dots Dashes w6wx 52 4.9 seconds 3.7 seconds 2.9 seconds 8 7 vk6rbp 74 7.1 seconds 5.3 seconds 4.3 seconds 15 8

[tomnd2t]

Alex, VE3NEA might know the answer as he is the author of Faros.

[wa5znu]

Does the first long dash start on a second boundary, or is it just some distance after the last letter of the call?

[wa5znu]

Changing to K6TD/B might make the perceived distance shorter if it's supposed to start on a boundary. The code currently starts on the same boundary for each beacon, not the "next" second.

[tomnd2t]

From listening, I believe it starts some distance from the last letter of the call -- no matter how long or short the call. Peter Jennings wrote in an email earlier today:

"... A quick glance at the old code gives the answer to the long dash timing. The CW ID is sent. Then there is a 54 x 4 mSec delay. Then the long dash is sent. ..."

[K6TD]

The full info from Peter is: http://www.ncdxf.org/beacon/source.txt

A quick glance at the old code gives the answer to the long dash timing.

The CW ID is sent. Then there is a 54 x 4 mSec delay. Then the long dash is sent. For perfect replication of the old beacon, the call overhead would also have to be factored in. Adding the overhead for 8748 assembler minus Arduino overhead, depending on clock frequency.

anl bus,#0efh ;key PTT on rig mov a,#mcall-100h ;transmit call call morse mov r7,#4 ;finish word space: wait four more els xmi5: call el djnz r7,xmi5

call long ;transmit one-second long dash

4U1UN/B is the longest call possible.

[K6TD]

The timing wheel increments in seconds. To fit in the 216ms delay, at the end of the call, we have to make the 1st long dash as part of the call time slot.

[tomnd2t]

Quick and possibly dirty solution: Wait until the next wheel increment (next second). See who complains / what breaks. It would be an easy way to know, by ear, whether an on-air beacon is v1 or v2.

[wa5znu]

That's definitely a good solution in my book! Leigh/Wa5ZNU

Quick and possibly dirty solution: Wait until the next wheel increment (next second). See who complains / what breaks. It would be an easy way to know, by ear, whether an on-air beacon is v1 or v2.

---

Reply to this email directly or view it on GitHub: https://github.com/IronHeartConsulting/IBPV2/issues/8#issuecomment-117860200

[tomnd2t]

And if too much breaks, repeat until it doesn't (divide each increment into 2, double counts, try again)

[K6TD]

Trying to test with FAROS. Once that picks up the new beacon, then we have timing right.