Skip to content

Releases: ericps1/crts

Fixed deadlock issue with TX_COMPLETE event

18 Apr 05:18
Compare
Choose a tag to compare

The deadlock occurred when the cognitive engine called tx_stop() and tx_start() within a single execution since the TX_COMPLETE event would attempt to lock the ce_mutex which was already locked by the execute function.

Spectrum Sharc Phase 3 Release

15 Apr 15:55
Compare
Choose a tag to compare

The main features included in this release include:

  • The addition of the scenario controller, which allows you to write a customized way of retrieving feedback and exerting control over all the nodes in the experiment. The method to define a new scenario controller is similar to the method used for cognitive engines.
  • Command line style arguments are now passed to the cognitive engine constructors, making it easy to parameterize them without needing to write a new cognitive engine definition.
  • An example scenario for handling dynamic network traffic loads in a cognitive radio network.

Fixed CE config issue in previous release.

06 Feb 03:44
Compare
Choose a tag to compare

config_CEs had been run with a CE that wasn't added to the repo.

Spectrum Sharc Phase 2 Initial Release

05 Feb 00:18
Compare
Choose a tag to compare

The main features added by this release include:

  • Control over the number of frames transmitted via ECR->start_tx_for_frames(int)
  • A method for estimating the ECR's physical layer throughput assuming perfect reception via ECR->get_tx_data_rate()
  • A way to simultaneously receive OFDM frames and perform spectrum sensing in the cognitive engine
  • Three different network traffic models (stream, burst, and poisson)

Mostly minor bug fixes

19 Nov 21:55
Compare
Choose a tag to compare

Fixed a couple of bugs pointed out by Spectrum-ShaRC contestants. Only one that was impacting performance was in the ECR::set_tx_subcarrier_alloc() function.

More improvements

12 Nov 04:42
Compare
Choose a tag to compare
  1. Previously if you tried to call an ECR::set_tx...() function while a frame was being transmitted the function call would hang until the transmission was ended. This was done for thread safety but it caused hang ups. Now these functions modify an intermediate struct and the transmitter is updated as necessary between transmissions.
  2. Depending on your configuration and sampling rates you can run the risk of saturating the processor. This results in overflows on the USRP receiver side and/or underruns at the transmit side. I've directed the relevant UHD messages so that they will trigger a CE event and can be dealt with accordingly.

Some bug fixes and improvements

11 Nov 04:52
Compare
Choose a tag to compare
  1. When using higher order modulation schemes the transmitter will stuff multiple packets from the TUN interface into a single OFDM frame so that the symbol length of the frame is consistent. The receive side was writing it to the TUN interface as a single packet which resulted in only the first packet actually getting through, severely reducing the perceived throughput. This issue has been addressed and throughput now scales as you would expect with modulation order.
  2. Made logging more efficient by opening and closing the file once rather than each time it is written.
  3. Changed rx worker to use a single call to the ofdmflexframe rather than an unnecessary loop and moved the USRP recv call out of the thread locking which helps with cleaning up the thread at the end of execution.
  4. Added changes made by Manolis Surligas which address the potential for EVM to be NaN in the FEC and Mod adaptation CE's.
  5. Fixed some typos.

Added octave plotting functions that had been removed accidentally.

29 Oct 19:16
Compare
Choose a tag to compare
v1.1.1

Added octave plotting functions that had been removed accidentally.