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

Transmitting SSTV with SX1268 suddenly breaks above 432 MHz #1171

Open
tsprinz opened this issue Jul 26, 2024 · 4 comments
Open

Transmitting SSTV with SX1268 suddenly breaks above 432 MHz #1171

tsprinz opened this issue Jul 26, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@tsprinz
Copy link

tsprinz commented Jul 26, 2024

Describe the bug
We are transmitting SSTV in Martin 2 mode from an SX1268. This works as expected on frequencies below 432 MHz. Changing the frequency to anything above 432 MHz (tested up to 437 MHz) leads to the signal becoming much more spread out and not decodable. The preamble appears at the expected location, only the image data part seems to break. Screenshots from a monitoring SDR are attached.

To Reproduce

#include <Arduino.h>
#include <RadioLib.h>

#define RADIO_DIO1 1
#define RADIO_DIO2 2
#define RADIO_TXEN 3
#define RADIO_RXEN 4
#define RADIO_BUSY 5
#define RADIO_RESET 6
#define RADIO_NSS 10

#include <img01.h>

SX1268 radio = new Module(RADIO_NSS, RADIO_DIO1, RADIO_RESET, RADIO_DIO2);
SSTVClient sstv(&radio);

// Custom ESP32 ISR
// https://github.com/jgromes/RadioLib/wiki/Interrupt-Based-Timing
hw_timer_t *My_timer = NULL;

void setFlag(void)
{
  radio.setTimerFlag();
}

void interruptSetup(uint32_t len)
{
  timerAlarmDisable(My_timer);
  timerAlarmWrite(My_timer, len, true);
  timerAlarmEnable(My_timer);
}

void setup()
{
  delay(3000);

  // use hardware timers for avoid floating sstv pictures
  My_timer = timerBegin(0, 80, true);
  timerAttachInterrupt(My_timer, &setFlag, true);

  radio.setInterruptSetup(interruptSetup);
  int state = radio.beginFSK();
  state = sstv.begin(432.000, Martin2);
}

void loop()
{
  sstv.sendHeader();

  for (uint16_t i = 0; i < sstv.getPictureHeight(); i++)
  {
    sstv.sendLine(img01[i]);
  }

  radio.standby();
  delay(2000);
}

Expected behavior
Changing the TX frequency should change where the signal appears in the spectrum, not how it looks.

Screenshots
Expected behaviour at 431.998 MHz:
Screenshot_2024-07-25_19-06-57

Unexpected behaviour at 432.000 MHz:
Screenshot_2024-07-25_19-08-15
Screenshot_2024-07-25_19-10-06

Additional info (please complete):

@jgromes
Copy link
Owner

jgromes commented Jul 26, 2024

I'm away from my "lab" at the moment, so I can't test, however, I would test the following:

  1. Does it still happen without interrupt timing?
  2. Does it still happen in AFSK mode?

@tsprinz
Copy link
Author

tsprinz commented Aug 1, 2024

Without interrupt timing

Without interrrupt timing it seems to be the same:

Minimal sketch without interrupt timing
#include <Arduino.h>
#include <RadioLib.h>

#define RADIO_DIO1 1
#define RADIO_DIO2 2
#define RADIO_TXEN 3
#define RADIO_RXEN 4
#define RADIO_BUSY 5
#define RADIO_RESET 6
#define RADIO_NSS 10

#include <img01.h>

SX1268 radio = new Module(RADIO_NSS, RADIO_DIO1, RADIO_RESET, RADIO_DIO2);
SSTVClient sstv(&radio);

void setup()
{
  delay(3000);

  int state = radio.beginFSK();
  state = sstv.begin(432.000, Martin2);
}

void loop()
{
  sstv.sendHeader();

  for (uint16_t i = 0; i < sstv.getPictureHeight(); i++)
  {
    sstv.sendLine(img01[i]);
  }

  radio.standby();
  delay(2000);
}

Waterfall images of running the code above

Screenshot_2024-07-28_20-26-31

Screenshot_2024-07-28_20-29-03

AFSK Mode

I did not get AFSK mode to work, it just seems to transmit a carrier for the duration of the image.

Minimal sketch for AFSK mode
#include <Arduino.h>
#include <RadioLib.h>

#define RADIO_DIO1 1
#define RADIO_DIO2 2
#define RADIO_TXEN 3
#define RADIO_RXEN 4
#define RADIO_BUSY 5
#define RADIO_RESET 6
#define RADIO_NSS 10

#include <img01.h>

SX1268 radio = new Module(RADIO_NSS, RADIO_DIO1, RADIO_RESET, RADIO_BUSY);
AFSKClient audio(&radio, RADIO_DIO2);
SSTVClient sstv(&audio);

void setup()
{
  delay(3000);
  int state = radio.beginFSK(431.990);
  state = sstv.begin(Martin2);
}

void loop()
{
  sstv.sendHeader();

  for (uint16_t i = 0; i < sstv.getPictureHeight(); i++)
  {
    sstv.sendLine(img01[i]);
  }

  radio.standby();
  delay(2000);
}

Waterfall images of running the code above

Screenshot_2024-08-01_16-02-58

@jgromes
Copy link
Owner

jgromes commented Aug 4, 2024

I was able to reproduce this behavior with SX1262. I'm suspecting some issue in the frequency calibration, but so far I did not manage to track down what exactly is causing this.

The workaround is to use AFSK mode, which works, but needs an extra pin (DIO2). It is also not as sensitive to changes in the carrier frequency, so I would strongly recommend trying to get AFSK working. Make sure the ESP32 pin connected to DIO2 can output PWM.

@jgromes jgromes added the bug Something isn't working label Aug 4, 2024
@tsprinz
Copy link
Author

tsprinz commented Aug 14, 2024

So far I've failed to get AFSK mode working. I've verified GPIO 2 of the ESP32 is connected to DIO2 on the module. As far as I understand, all GPIOs of the ESP32 should be able to output PWM. I'm getting the following error message through the serial port with the code in my last post:

E (3062) ledc: ledc_get_duty(745): LEDC is not initialized

I tried changing ArduinoHal.cpp lines 127ff.

      #if !defined(ESP_IDF_VERSION) || (ESP_IDF_VERSION < ESP_IDF_VERSION_VAL(5,0,0))
      ledcAttachPin(pin, RADIOLIB_TONE_ESP32_CHANNEL);

to

      #if !defined(ESP_IDF_VERSION) || (ESP_IDF_VERSION < ESP_IDF_VERSION_VAL(5,0,0))
      ledcSetup(RADIOLIB_TONE_ESP32_CHANNEL, frequency, 14);
      ledcAttachPin(pin, RADIOLIB_TONE_ESP32_CHANNEL);

which silenced the error message, but did not result in different spectral output. Note I'm running arduino-esp32 v2.0.17 based on ESP-IDF v4.4.7 as this is still the default in Platform.io.

I also tried manually updating to arduino-esp32 v3.0.4 based on ESP-IDF v5.1.4, which again silenced the error message, but did not result in different spectral output.

Do you have any suggestions on how to get this working?

@jgromes jgromes self-assigned this Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants