Added fix in the scope of issue #365

firmware/application/radio.cpp

@@ -111,14 +111,12 @@ void set_direction(const rf::Direction new_direction) {
 	// Hack to fix the CPLD (clocking ?) bug: toggle CPLD SRAM overlay depending on new direction
 	// Use CPLD's EEPROM config when transmitting
 	// Use the SRAM overlay when receiving
-	if (direction != new_direction) {
-		if (new_direction == rf::Direction::Transmit) {
-			hackrf::cpld::init_from_eeprom();
-		} else {
-			if( !hackrf::cpld::load_sram() ) {
-				chSysHalt();
-			}
-		}
+
+	// teixeluis: undone "Hack to fix the CPLD (clocking ?) bug".
+	// Apparently with current CPLD code from the hackrf repo,
+	// toggling CPLD overlay should no longer be necessary:
+	if (direction != new_direction && new_direction == rf::Direction::Transmit) {
+		hackrf::cpld::init_from_eeprom();
 	}
 
 	direction = new_direction;

firmware/application/receiver_model.cpp

@@ -171,7 +171,11 @@ void ReceiverModel::enable() {
 	update_baseband_bandwidth();
 	update_sampling_rate();
 	update_modulation();
+
+	// TODO: would challenge if this should belong to the
+	// receiver_model namespace:
 	update_headphone_volume();
+
 	led_rx.on();
 }
 
@@ -182,6 +186,10 @@ void ReceiverModel::disable() {
 	// TODO: Responsibility for enabling/disabling the radio is muddy.
 	// Some happens in ReceiverModel, some inside radio namespace.
 	radio::disable();
+
+	// TODO: we are doing this repeatedly in different levels of the
+	// call stack. Keeping it for now, but there seem to be too many
+	// redundant calls:
 	led_rx.off();
 }