int power=0;
#ifdef STEMLAB_FIX
//
- // DL1YCF:
- // On my HAMlab RedPitaya-based SDR transceiver, CW is generated on-board the RP.
- // However, while in CW mode, DriveLevel changes do not become effective.
+ // Some HPSDR apps for the RedPitaya generate CW inside the FPGA, but while
+ // doing this, DriveLevel changes are processed by the server, but do not become effective.
// If the CW paddle is hit, the new PTT state is sent to piHPSDR, then the TX drive
// is sent the next time "command 3" is performed, but this often is too late and
// CW is generated with zero DriveLevel.
current_rx=0;
#ifdef STEMLAB_FIX
- // DL1YCF:
- // My RedPitaya HPSDR "clone" won't start up
- // if too many commands are sent here. Note these
- // packets are only there for sync-ing in the clock
- // source etc.
- // Note that always two 512-byte OZY buffers are
- // combined into one METIS packet.
+ //
+ // Some (older) HPSDR apps on the RedPitaya have very small
+ // buffers that over-run if too much data is sent
+ // to the RedPitaya *before* sending a METIS start packet.
+ // Therefore we send only four OZY buffers here.
//
command=1; // ship out a "C0=0" and a "set tx" command
ozy_send_buffer();
sprintf(name,"receiver.%d.sample_rate",rx->id);
value=getProperty(name);
if(value) rx->sample_rate=atoi(value);
+#ifdef STEMLAB_FIX
+ // HPSDR apps on the RedPitay have hard-wired connections
+ // that should not be changed
+ fprintf(stderr,"STEMLAB: ignoring ADC settings for RX%d\n",rx->id);
+#else
sprintf(name,"receiver.%d.adc",rx->id);
value=getProperty(name);
if(value) rx->adc=atoi(value);
+#endif
sprintf(name,"receiver.%d.filter_low",rx->id);
value=getProperty(name);
if(value) rx->filter_low=atoi(value);
}
break;
}
+#ifdef STEMLAB_FIX
+//
+// RedPitaya based HPSDR apps have hard-wired adc settings
+//
+ if (id == 1) rx->adc=1;
+#endif
}
fprintf(stderr,"create_receiver: id=%d default ddc=%d adc=%d\n",rx->id, rx->ddc, rx->adc);
rx->sample_rate=48000;