Hi Berndt,
Thanks for code checked-in about the FT990 and sorry for the mispelling.
This is right in time for the Hamlib 1.2.5 release.
BTW, you made the same mistake I made couple of month ago, to post on
discuss-gnuradio instead of hamlib-developer mailing list :-)
No trouble on that, the Repl
I've been collecting snapshots through my DBS and USRP to do DBPSK and DQPSK
bit error rate testing. I'm not able to get the BER below about 1e-5. It
seems that slips are occuring spontaneously in the data even though no
over/underflow is reported during the collection.
Questions:
1. Has anyon
You'll want to strip out the extra receiver. The default fpga is 2 rx and 1
tx. You probably don't need the second RX for your application. You also may
not need the halfband filter on your receiver.
In the past I've stripped down to a single RX and got utilization down to
about 30%. You'll pr
G'day,
I've updated code supporting the FT990 rig.
It fixes a bug that caused set_mode() to interchange the RTTY and RTTYR modes.
It fixes several bugs in get_channel(). in particular the reporting of
transmitter parameters in split modes. Valid values for the channel parameter
are channel nu
Hello!I am trying to implement a CSMA/CA typish MAC layer protocol. something like RTS-CTS-DATA-ACK type packet exchange. The idea to move some functionality on FPGA.The idea is to maintain two speperate buffers, one for DATA packets and the other for RTS packets. so that over multiple rounds of
