Count me in. Mr. Lloyd wrote: > And I am personally not moved by the, "we must be efficient and > preserve > bandwidth," argument either. Our command/status channel is going to be > a > mere drop-in-the-bucket compared to the IF and baseband data streams so > giving up some protocol efficiency in order to gain programming and > debugging simplicity is likely to be an overall win. >
I agree 100% I'm not sure if TCP is the right protocol here, or whether UDP fits better. But an IP-based mechanism is almost surely the easiest from many different viewpoints. Mr. McKenzie wrote: > > I'd like to see an event subscription-based replacement to CAT that > lets a > developer subscribe to be notified when certain events occur. This > allows a > logbook or contesting software programmer to "subscribe" to frequency > changes, mode changes, transmit, etc. without the need to poll > constantly > for data. Absolutely agreed. What's nice about a subscriber-based model is that it allows simple expansion of the events produced, without any disruption in the consumer. I want to see Frequency Changes, I see frequency changes. Later, an event is added to be informed about callsigns, unless I also subscribe to that event I just see frequency changes. Further, it probably makes sense to at least consider making this protocol a "mesh" and not merely "one to many" -- That is, any module can be a producer or a consumer of events. It makes the registration and switching more complex, but it allows infinite variety and expandability. Mr. Lloyd again: > > One of the key issues is the need (or lack of need) to synchronize > commands/status with IF and baseband data. Must it be isochronous or > can it > be asynchronous? So far in my mind it appears asynchronous but I think > we > need to come up with usage scenarios that let us test our assumptions > using > mind experiments. > Yes, good point. I *think* the events themselves can be asynchronous, but it's worthy of discussion. Also (if there's a need to ensure time-relevance) events could be time stamped. The problem with this is, of course, clock skew if there are multiple producers/consumers. Peter K1PGV _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using alpha and beta versions of the software.
