I've successfully run the FSK application on my hardware I am porting to, but the small file transfer is not sufficient and I want to create an FSK BER application. I am curious if anyone has implemented something like this functionality in OpenCPI and/or if anyone has any tips or suggestions on how to start? My plan was to re-use the basis of the FSK application, (MFSK Mapper, filters, CORDIC's, etc) but turn a long burst into a rolling stream with loss of sync and BER counts reported every second until ^C is hit. If someone has something like this already done and can supply a link, that would be much appreciated. Otherwise, any guidance or tips are also appreciated. Thanks, Brian

Your willingness to inquire as to existing capabilities, and collaborate on generic, reusable solutions is much appreciated. HISTORY OF NON-GENERIC BER CAPABILITIES: There are some AD9361-in-the-loop test apps (assets project ad9361_adc_test/ad9361_dac_test) which perform BER calculations, but these are very AD9361-specific at the moment. IDEAS FOR GENERIC BER CAPABILITIES: * new xor component (many use cases), new switch component (many use cases), new BER calc component * example BER app: - known-good data source -> xor component input port in0 - data source on which to calculate BER -> xor component input port in1 - xor component output port -> some component to count number of 1s, number of 0s, BER property= nOnes/(nZeros+nOnes) - pattern-switch component only turns the switch "on" to send data to xor once a (sync) pattern is observed * might this be suitable to fit your use case? * I have some preliminary implementations for xor.hdl, and switch.hdl w/ unit tests - I can commit to a gitlab branch if you think it useful ---------- Forwarded message --------- From: Brian Padalino <bpadalino@gmail.com> Date: Fri, Mar 6, 2020 at 12:18 AM Subject: [Discuss OpenCPI] FSK BER Test To: <discuss@lists.opencpi.org> I've successfully run the FSK application on my hardware I am porting to, but the small file transfer is not sufficient and I want to create an FSK BER application. I am curious if anyone has implemented something like this functionality in OpenCPI and/or if anyone has any tips or suggestions on how to start? My plan was to re-use the basis of the FSK application, (MFSK Mapper, filters, CORDIC's, etc) but turn a long burst into a rolling stream with loss of sync and BER counts reported every second until ^C is hit. If someone has something like this already done and can supply a link, that would be much appreciated. Otherwise, any guidance or tips are also appreciated. Thanks, Brian

On Fri, Mar 6, 2020 at 1:16 PM Davis Hoover <dhoover@geontech.com> wrote: > Your willingness to inquire as to existing capabilities, and collaborate on > generic, reusable solutions is much appreciated. > Not a problem. I'm pretty impressed with the framework so it's decently fun getting more into it. > > HISTORY OF NON-GENERIC BER CAPABILITIES: > There are some AD9361-in-the-loop test apps (assets project > ad9361_adc_test/ad9361_dac_test) which perform BER calculations, but these > are very AD9361-specific at the moment. > Thanks for pointing this out. I saw them previously for testing the ADC/DAC BIST modes and found them useful. > > IDEAS FOR GENERIC BER CAPABILITIES: > * new xor component (many use cases), new switch component (many use > cases), new BER calc component > * example BER app: > - known-good data source -> xor component input port in0 > - data source on which to calculate BER -> xor component input port in1 > - xor component output port -> some component to count number of 1s, > number of 0s, BER property= nOnes/(nZeros+nOnes) > - pattern-switch component only turns the switch "on" to send data to > xor once a (sync) pattern is observed > * might this be suitable to fit your use case? > * I have some preliminary implementations for xor.hdl, and switch.hdl w/ > unit tests - I can commit to a gitlab branch if you think it useful > I definitely think they would be useful, though, in the past, I've implemented this using an LFSR and an FSM which is first UNLOCKED and uses the input bits to try to feed an LFSR prediction. Once N bits have been successfully predicted from the data stream, we switch over to LOCKED and we start counting bits. If we ever get a point where ~50% of the incoming bits are in error, we transition back to UNLOCKED. This seems to be the thing that would control the pattern-switch component, with the xor component being the comparison of total bits to 1 bits. I suppose this piece would be an LFSR sync which would be the known-good data source as well as the pattern switch input? Or does it just turn into a single block with 2 outputs? When it comes to development, it seemed potentially easier to write it all as RCC components first and then switch to HDL components afterwards. Is thsi the way development of most signal processing applications are done, or does development typically dive directly into the HDL immediately? I definitely won't say no to a pushed branch with some HDL components to it. It might even give me a chance to write the RCC components as the comparison. Brian