Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop a Singlecarrier PHY Layer #25

Open
5 of 9 tasks
lukasostendorf opened this issue Jul 6, 2020 · 3 comments
Open
5 of 9 tasks

Develop a Singlecarrier PHY Layer #25

lukasostendorf opened this issue Jul 6, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@lukasostendorf
Copy link
Collaborator

lukasostendorf commented Jul 6, 2020

The given channel bandwidth of 200 kHz is somewhat of an edge-case in terms of frequency selectiveness. Lower channel bandwidths will undergo flat fading, higher bandwidths will undergo frequency selective fading.

For a flat fading scenario, a singlecarrier solution would also be easy to implement and will make it easier to find a PA which amplifies the signal (due to lower PAPR). In case of high frequency selectiveness, the OFDM PHY layer is expected to be more robust but requires a very linear PA.

In order to compare both approaches, we will develop a singlecarrier version of the PHY layer which is compatible to the existing MAC layer.

Tasks

  • definition of the SC PHY layer
  • general single carrier modulation functions
  • new timing synchronization sequence and correlation algorithm
  • include pulse shaping
  • include training sequences and a LMS equalizer
  • integrate SC phy to current develop branch

Open Issues

  • compensate constant phase offsets
  • Initialize Platform for 300kSyms/s instead of the 256kSyms/s
  • Training sequences are currently transmitted regardless whether data is transmitted in a slot. Fix this

SC PHY Definition

  • 300 kSymb/s sampling rate
  • RRC filter for pulse shaping, with factor 2 interpolation/decimation -> 150 kSymb/s baseband sampling rate
  • LMS Equalizer with 8 (?) taps
  • Every data slot will contain 40 training symbols at the beginning of the slot followed by 520 data symbols
  • Synchronization sequence is a 119 symbol Zadoff Chu sequence
  • Zadoff chu is also used in uplink for initial sync.

Related working branch https://github.com/HAMNET-Access-Protocol/HNAP4PlutoSDR/tree/singlecarrier_phy

@lukasostendorf lukasostendorf added the enhancement New feature or request label Jul 6, 2020
@kantooon
Copy link

kantooon commented Aug 9, 2020

Hi @lukasostendorf I watched your SDRA talk and think that depending on how much bandwith you are willing to sacrifice, you might use FSK instead of PSK to be able to work with class C amplifiers. I recently implemented a 4FSK (RRC and 1/2 rate convolutional code) 96 kbit/s modem in qradiolink and am quite satisfied with RF performance on a regular FM amplifier.

@DG9BFC
Copy link

DG9BFC commented Oct 21, 2020

hmmm single carrier ?? why not also add slower packet speeds?? on pluto you sure can transmit also in 1k2 2k4 4k8 9k6 and higher ... one unit fits all ... slow speed packet ... high speed packet ... hamnet ... whatevernet

@dranch
Copy link

dranch commented Dec 8, 2020

Will this enhancement be able to lower HNAP's consumed bandwidth to 100Khz and lower the symbol rate to 56KSymbols/sec? This would be great to have to meet the USA's FCC requirements. Here is some back ground of the ARRL trying to get these limitations changed but it's been 5yrs with no movement: https://www.federalregister.gov/documents/2016/08/12/2016-19085/amateur-radio-service-rules-to-permit-greater-flexibility-in-data-communications )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants