Unclear if you mean that for transmission event covering multiple frames, or actual signal transmitting, I could see both being useful. There are use cases for having another application be aware of each radio state change (whether tx hold is on between frames or not), of tx signal presence, and of end of transmit event for multiple frames.

The object could contain several properties of interest and could either be emitted around every frame:

// At the start of a 2 frame transmission
{
	"type": "TX.START",
	"params": {
		"frame": 1,
		"frames_queued": 1
	}
}
// Once frame 1 has been sent
{
	"type": "TX.END",
	"params": {
		"frame": 1,
		"frames_queued": 1,
		"tx_hold": true // indicating there is more to send
	}
}
// Sending frame 2
{
	"type": "TX.START",
	"params": {
		"frame": 2,
		"frames_queued": 0
	}
}
// Once frame 2 has been sent
{
	"type": "TX.END",
	"params": {
		"frame": 2,
		"frames_queued": 0,
		"tx_hold": false // nothing else to send
	}
}

Or that may be too verbose, in which case just "wrap" the entire transmission:

// At the start of a 2 frame transmission
{
	"type": "TX.START",
	"params": {
		"frame": 1,
		"frames_queued": 1
	}
}
// Once both frames have been sent
{
	"type": "TX.END",
	"params": {
		"frame": 2,
		"frames_queued": 0
	}
}

In the apps I have made using my lib, I haven't actually needed frame info, just whether it is safe to pass some text to TX, so I just wished for:

// Send at the start of ANY transmission
{
	"type": "RIG.SAFE_TO_TX",
	"value": false
}
// Send when PTT switches off AND the send buffer is empty
{
	"type": "RIG.SAFE_TO_TX",
	"value": true
}

I implemented this event into js8-lib by manually checking the buffer contents with TX.GET_TEXT, but it would be much better as a proper API event.

There is no RIG.GET_PTT so we can't just query the current status at the moment we wish to send text, we have to just keep track of RIG.PTT packets we've seen. I guess a more low level solution would be for JS8 to just allow adding more text to the buffer without the external app having to manage when it's ok to send text (I don't actually know if that's desirable or not).

Uh oh!

The Great API rework #87

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions