tomdowad commented 2 years ago

Please read about common issues first. It addresses the most common problems that people have (whether they know it or not).

Describe the bug A clear and concise description of what the bug is.

Please include:

Code to reproduce
Expected behaviour
What device(s) are you using? Please specify make, model, and Operating System if applicable.

Additional context Add any other context about the problem here.

2bndy5 commented 2 years ago

What link are you using? I don't get a 404 from either http://nrf24.github.io/RF24 or https://rf24.rtfd.io

tomdowad commented 2 years ago

Hey Brendan

Thanks for quick reply. Yes your link works. It is the one on main_page.md...that has, for class docs, this link:

https://github.com/nRF24/RF24/blob/master/docs/classRF24.html

On Tue, Nov 30, 2021 at 5:28 PM Brendan @.***> wrote:

What link are you using? I don't get a 404 from either http://nrf24.github.io/RF24 or https://rf24.rtfd.io

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-983195387, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIC3RA5DMZRK2WXJEKTUOV23XANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

2bndy5 commented 2 years ago

@tomdowad You are trying to click the relative link from the repo's docs folder on github. I left a README in the docs folder to warn against doing this. Please browse the docs from either of the 2 links I provided above. The docs folder you are browsing is meant only for viewing, not browsing; please read the README in the docs folder.

I suppose I should reiterate this info in that README file, but it wouldn't help any if people don't read it at all.

tomdowad commented 2 years ago

FYI all I am trying to do is a virtual serial port. I didn't see one in your examples. Once I have it working I will send it to you.

On Tue, Nov 30, 2021 at 5:36 PM Tom Dowad @.***> wrote:

Hey Brendan

Thanks for quick reply. Yes your link works. It is the one on main_page.md...that has, for class docs, this link:

https://github.com/nRF24/RF24/blob/master/docs/classRF24.html

On Tue, Nov 30, 2021 at 5:28 PM Brendan @.***> wrote:

What link are you using? I don't get a 404 from either http://nrf24.github.io/RF24 or https://rf24.rtfd.io

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-983195387, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIC3RA5DMZRK2WXJEKTUOV23XANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

2bndy5 commented 2 years ago

FYI all I am trying to do is a virtual serial port.

This seems like a separate issue, and I'm not really sure what you mean by "virtual serial port".

I've updated the README, so I'm closing this.

@tomdowad Please don't send me a personal email. Open Source communities thrive better when the entire community is involved. Instead, open another issue and upload your solution to the issue's Originating Post (OP) as a zip file.

Note: attaching zip files to emails will not work as a response to issues on github.
Pro-tip: you can keep commenting on a closed thread if it is relevant.

2bndy5 commented 2 years ago

@tomdowad Does this sketch help?

tomdowad commented 2 years ago

Re "virtual serial port"

Kinds of like those Bluetooth serial devices, which provide am apparently full duplex connection over the air. I have two Arduinos, each with an NRF24L01 I have Mac Terminal running on two Macs, each connected to one of the Arduinos. The sketch reads Serial then if any characters are there, puts them into a packet which gets sent via your library to the other Arduino This works fairly well for sending in one direction. I am getting a bit hung up on turning around and sending back the other way. I am making on Arduino the master, the other the slave. When the master sends & slave receives, they swap. The slave immediately sends back its packet. But its not working. Probably my code.

The problem, always, with docs and such is that you don't know what you don't know. And adding more docs often makes it worse, because it makes it harder to find what you need to know.

My intuition tells me I should go into README.md (the one displayed by default on Github) and look for a link to the API description. That's kind of the first thing, for me at least. I want a description for idiots, for the most basic functionality. The docs you sent are good. What I needed to know was that your code blocks in the write method. So that means, as soon as write returns, I should be able to call startListening.

On Tue, Nov 30, 2021 at 5:56 PM Brendan @.***> wrote:

FYI all I am trying to do is a virtual serial port.

This seems like a separate issue, and I'm not really sure what you mean by "virtual serial port".

I've updated the README, so I'm closing this.

@tomdowad https://github.com/tomdowad Please don't send me a personal email. Open Source communities thrive better when the entire community is involved. Instead open another issue and upload you solution to the issue's Original Post (OP) as a zip file.

Note: attaching zip files to emails will not work as a response to issues on github.

Pro-tip: you can keep commenting on a closed thread if it is relevant.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-983208740, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIBYJRVOSK4RQQZYRKLUOV6GFANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

2bndy5 commented 2 years ago

It sounds like you should take a look at the ManualAcknowledgement.ino example (& pay attention to the comments). The problem I have had with that example is often timing, especially if you speed it up by taking the delay() out of the loop.

A more reliable solution (for me) has been making use of ACK payloads in the auto-ack packets. See the AcknowledgementPayloads.ino example for that solution.

The description of your project sounds like this RF24MeshSerial library (seems actively supported by the author,), but it is not part of the nRF24 org.

Pros	Cons
Payloads aren't strictly limited to 32 bytes since it uses the RF24Mesh network layer	Requires a basic understanding of the RF24Mesh network layer

Unfortunately, reading the docs is a lot like reading any complex manual/instructions - there's a bit of a learning curve just to navigate them. Personally, I don't like the way you're expected to navigate nRF24.github.io/RF24, but it has a bit more detail than the prettier/modernized rf24.rtfd.io docs (for now).

tomdowad commented 2 years ago

Actually it turned out to be simple. The code I had written works. The problem was, one of my two (somewhat hand-wired) Nanos w/NRF24L01 could not transmit (or the other couldn't receive). I haven't figured out why yet.

I got a couple of those RF Nanos from Aliexpress, and with that hardware it works. I will clean it up a bit then send you the sketch.

On Tue, Nov 30, 2021 at 9:45 PM Brendan @.***> wrote:

It sounds like you should take a look at the ManualAcknowledgement.ino https://github.com/nRF24/RF24/blob/master/examples/ManualAcknowledgements/ManualAcknowledgements.ino example (& pay attention to the comments). The problem I have had with that example is often timing, especially if you speed it up by taking the delay() out of the loop.

A more reliable solution (for me) has been making use of ACK payloads in the auto-ack packets. See the AcknowledgementPayloads.ino https://github.com/nRF24/RF24/blob/master/examples/AcknowledgementPayloads/AcknowledgementPayloads.ino example for that solution.

The description of your project sounds like this RF24MeshSerial library https://github.com/BCsabaEngine/RF24MeshSerial (seems actively supported by the author,), but it is not part of the nRF24 org. Pros Cons Payloads aren't strictly limited to 32 bytes since it uses the RF24Mesh network layer Requires a basic understanding of the RF24Mesh network layer

Unfortunately, reading the docs is a lot like reading any complex manual/instructions - there's a bit of a learning curve just to navigate them. Personally, I don't like the way you're expected to navigate nRF24.github.io/RF24, but it has a bit more detail than the prettier/modernized rf24.rtfd.io docs (for now).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-983308976, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIFWFM3ZR2IH423J4W3UOWY6JANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

tomdowad commented 2 years ago

Hi Brendan

I am sending you the serial com link sketch that uses the RF24 library It works, but its very slow. I had a look on the protocol analyser. There is a ton of activity on the SPI (looks like its polling, writing FFs), which periodically seems to stop, then resume. Looking at both sides of the NRF wireless connection, it looks like one packet gets through per 100 ms. My code tries to send a packet from the Host every 20 ms, and the MCU (slave device) is meant to respond immediately to each host packet. I think the code is pretty much self-evident. If you want to try it with a couple of terminal connections, enable #define DEBUG

Regards Tom

On Thu, Dec 2, 2021 at 11:45 AM Tom Dowad @.***> wrote:

Actually it turned out to be simple. The code I had written works. The problem was, one of my two (somewhat hand-wired) Nanos w/NRF24L01 could not transmit (or the other couldn't receive). I haven't figured out why yet.

I got a couple of those RF Nanos from Aliexpress, and with that hardware it works. I will clean it up a bit then send you the sketch.

On Tue, Nov 30, 2021 at 9:45 PM Brendan @.***> wrote:

It sounds like you should take a look at the ManualAcknowledgement.ino https://github.com/nRF24/RF24/blob/master/examples/ManualAcknowledgements/ManualAcknowledgements.ino example (& pay attention to the comments). The problem I have had with that example is often timing, especially if you speed it up by taking the delay() out of the loop.

A more reliable solution (for me) has been making use of ACK payloads in the auto-ack packets. See the AcknowledgementPayloads.ino https://github.com/nRF24/RF24/blob/master/examples/AcknowledgementPayloads/AcknowledgementPayloads.ino example for that solution.

The description of your project sounds like this RF24MeshSerial library https://github.com/BCsabaEngine/RF24MeshSerial (seems actively supported by the author,), but it is not part of the nRF24 org. Pros Cons Payloads aren't strictly limited to 32 bytes since it uses the RF24Mesh network layer Requires a basic understanding of the RF24Mesh network layer

Unfortunately, reading the docs is a lot like reading any complex manual/instructions - there's a bit of a learning curve just to navigate them. Personally, I don't like the way you're expected to navigate nRF24.github.io/RF24, but it has a bit more detail than the prettier/modernized rf24.rtfd.io docs (for now).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-983308976, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIFWFM3ZR2IH423J4W3UOWY6JANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

2bndy5 commented 2 years ago

I am sending you the serial com link sketch

I've said this before: You cannot attach files to email and expect the attachments to be posted on github. The post that email created has no download for a sketch. I think github prevents this out of concern for malicious activity.

There is a ton of activity on the SPI (looks like its polling, writing FFs)

This is the getStatus() function polling the radio during any write() call or available() call. This is normal. In fact, if RF24's debug output (via RF24_config.h) is enabled, I have excluded the FF writes over SPI to prevent serial monitor clutter. I don't know if you're using this debug output to compare with the signal analyzer, but it is something to look out for if/when you do.

it looks like one packet gets through per 100 ms.

To be clear, do you mean milliseconds (AKA ms) or microseconds (AKA us)?

tomdowad commented 2 years ago

Hi Brendan

Right. I assumed the email address was your email, but I see its via github. To work around, I pasted the sketch code into this email.

OK thanks for tip re FFs. I think I need to dig into the RF24 code at this stage. I'll try that ....tomorrow.

Milliseconds. I'm using a Saleae protocol/logic analyser with their Logic software. To be fair, there is another MCU involved. So an RFNano sends the message to another Nano which is talking via an NRF24L01 module. Then that Nano passes the characters on to another MCU which echoes every character received. The baud rate is 57600. On a direct connection via USB-to-Serial, the echo would take a millisecond. So there is a little more delay than one would have with a loopback test.

Code below FYI. If I can get it going well I will share it on github.

Thx Tom

//------------------------------------------------------------------------------ // INCLUDES //------------------------------------------------------------------------------

include

include "RF24.h"

//------------------------------------------------------------------------------ // DEFINES //------------------------------------------------------------------------------

//#define DEBUG

define uchar uint8_t

define PAYLOAD_SIZE 8

define HOST_TX_PERIOD 20

define PIN_RADIO_CE 9 // RX/TX pin

define PIN_RADIO_CSN 10 // SPI chip select

//#define PIN_RADIO_CE 10 // error in my prototype wiring, so reversed them //#define PIN_RADIO_CSN 9

define RX_TIMEOUT 100

define RADIO_ID_SELF 1

define RADIO_ID_MCU 0

define RADIO_DATA_HOST 0

define RADIO_DATA_SLAVE 1

struct RadioPacket { uint8_t nText; char text[PAYLOAD_SIZE]; };

//------------------------------------------------------------------------------ // VARIABLES //------------------------------------------------------------------------------

uint32_t lastTxTime;

RF24 myRadio(PIN_RADIO_CE, PIN_RADIO_CSN); uint8_t address[2][6] = {"1Node","2Node"};

uint8_t numSends = 0; char curMode = 0;

RadioPacket radioDataIn; RadioPacket radioDataOut;

//------------------------------------------------------------------------------ // CODE //------------------------------------------------------------------------------

void setup() { uchar addr;

pinMode(2,OUTPUT);
digitalWrite(2,1);
Serial.begin(57600);

ifdef DEBUG

Serial.print("\n\rNRF24L01 Dec 8 2021: ");

endif

if (!myRadio.begin())
{

ifdef DEBUG

    Serial.print("init failed");

endif

    while (1);                      // wait here forever.
}
else
{
   myRadio.setPALevel      (RF24_PA_HIGH);
   myRadio.setPayloadSize  (sizeof(RadioPacket));
}

ifdef DEBUG

Serial.print(" running");
// enter the mode
while((curMode != 'M') && (curMode != 'H'))
{
    Serial.print("\nSelect Host or MCU (H or M)");
    while(!Serial.available())
        ;
    curMode = Serial.read();
}
Serial.print("\n\rNRF24L01 ");
Serial.print((curMode == 'H') ? "HOST" : "MCU");

else

curMode = 'H';          // host mode
curMode = 'M';        // mcu mode

endif

addr = (curMode == 'H') ? 0 : 1;
myRadio.openWritingPipe (   address[addr]);
myRadio.openReadingPipe (1, address[addr ^ 1]);
myRadio.startListening  ();

lastTxTime = millis();

}

void loop() { char c; uint8_t n; uint8_t i;

if(curMode == 'H')
{
    if((millis() - lastTxTime) > HOST_TX_PERIOD) // exchange every n ms
    {
        lastTxTime = millis();
        radio_send();                            // send what we've got

(or empty packet) radio_receive(); // slave unit will send back what its got } } else { myRadio.startListening(); // wait for a packet while(!myRadio.available()) ; uint8_t bytes = myRadio.getPayloadSize(); // get it myRadio.read(&radioDataIn, bytes); radio_unload (&radioDataIn); // act on it delay(2); radio_load (&radioDataOut); // and send one back

ifdef DEBUG

    radio_unload (&radioDataOut);

endif

    myRadio.stopListening();
    myRadio.write(&radioDataOut,sizeof(RadioPacket));
    delay(1);
}

}

//------------------------------------------------------------------------------ // CODE: HOST //------------------------------------------------------------------------------

// NAME: radio_send // DESCRIPTION: Send whatever serial data we have void radio_send() { myRadio.stopListening(); // put radio in RX mode radio_load (&radioDataOut); // load packet from serial

ifdef DEBUG

if(radioDataOut.nText != 0) { Serial.print("Sending "); Serial.print(radioDataOut.nText); Serial.print(" "); radio_unload (&radioDataOut); // echo chars typed }

endif

myRadio.write   (&radioDataOut,sizeof(RadioPacket));
delay(1);
myRadio.startListening();

}

// NAME: radio_receive // DESCRIPTION: Host receiver void radio_receive() { bool done = false; uint8_t bytes; uint32_t rxStartTime;

myRadio.startListening(); // put radio in RX mode
rxStartTime = millis();
while(!done)
{
    if(myRadio.available())
    {
        bytes = myRadio.getPayloadSize(); // get the size of the payload
        myRadio.read(&radioDataIn, bytes);
        if(bytes == sizeof(RadioPacket))
        radio_unload(&radioDataIn);
        done = true;
    }
    done = ((millis() - rxStartTime) > RX_TIMEOUT);      // wait up to

n ms } }

//------------------------------------------------------------------------------ // CODE: SHARED //------------------------------------------------------------------------------

// NAME: radio_load // DESCRIPTION: Load data into the packet void radio_load(RadioPacket *rd) { char c; uint8_t n;

rd->nText = 0;
for(n = 0;n < PAYLOAD_SIZE;n++)
{
    if(Serial.available())
    {

        c = Serial.read();
        rd->text[n] = c;
        ++n;
        rd->nText = n;
    }
    else
        break;
}

}

// NAME: radio_unload // DESCRIPTION: Unload data from the packet void radio_unload(RadioPacket *rd) { char c; uint8_t n; uint8_t i;

n = rd->nText;
if(n > 0)
{
    for(i = 0;i < n;i++)
    {
       c = rd->text[i];
       if(c != 0)             // had a problem with receiving NULs
           Serial.write(c);
    }
}

}

On Wed, Dec 8, 2021 at 3:14 PM Brendan @.***> wrote:

I am sending you the serial com link sketch

I've said this before: You cannot attach files to email and expect the attachments to be posted on github. The post that email created has no download for a sketch. I think github prevents this out of concern for malicious activity.

There is a ton of activity on the SPI (looks like its polling, writing FFs)

This is the getStatus() function polling the radio during any write() call or available() call. This is normal. In fact, if RF24's debug output (via RF24_config.h) is enabled, I have excluded the FF writes over SPI to prevent serial monitor clutter. I don't know if you're using this debug output to compare with the signal analyzer, but it is something to look out for if/when you do.

it looks like one packet gets through per 100 ms.

To be clear, do you mean milliseconds (AKA ms) or microseconds (AKA us)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-989303307, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIBW36DUIPKZ66A5I2LUP7RD5ANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

2bndy5 commented 2 years ago

Well, I'm glad you got it working, but I don't think it would be a valuable addition to the docs' examples.

It would be yet another example (among the existing 6 exemplified features * 4 platforms = 24 distinct examples) that we would have to maintain (with or without your help).
It is a specific use case, and I don't want people to think the library is meant solely for 1 usage.
I try to refrain from using the docs like a "show-n-tell"; for that we can put a link in the main page to your project (assuming you create a repository on github to host it).

If there's a problem you're trying to work through, please open a new issue so we can discuss it. Github issues are supposed to be focused on a particular issue; this issue is turning into a reddit thread.

So there is a little more delay than one would have with a loopback test.

In my experience, using any Serial-type objects will significantly slow down the application (despite what the baud rate is set to). I do my best to avoid Serial interactivity.

To work around, I pasted the sketch code into this email.

Please refrain from doing that in the future because:

not all emails (more specifically email apps) use the same UTF codeset that github would expect/prefer
- I cannot edit the resulting post to use syntax highlighting
- I cannot quote a snippet from your email in my reply because of different line endings
it makes the thread VERY long, thus harder to traverse
some lines seem to be truncated or wrapped incorrectly, although this may have been related to your copy-n-paste attempt.
If you're going to use github to share code, then use github.com (the website) or git bash for more serious users.
- The email interactions are secondary and meant for feed subscription notifications (like RSS feeds).
- Github is not a social media platform, and the website's interactions have been vastly improved over the last few years.

Sorry if this is too blunt, but I have had to explain this more than once (especially in this thread). And it is always toward people that don't know/understand github better.

tomdowad commented 2 years ago

Sorry Brenden, I didn't mean to trouble you. You are right -- I am not a github user by-and-large and not into open-source much, other than being an Arduino user.

I thought I would give a try at using Arduino for this task, but there are so many unknowns regarding timing, I'm afraid I am going to have to write my own driver.

Thanks for your time!

On Wed, Dec 8, 2021 at 5:11 PM Brendan @.***> wrote:

Well, I'm glad you got it working, but I don't think it would be a valuable addition to the docs' examples.

It would be yet another example (among the existing 6 exemplified features * 4 platforms = 24 distinct examples) that we would have to maintain (with or without your help).

It is a specific use case, and I don't want people to think the library is meant solely for 1 usage.

I try to refrain from using the docs like a "show-n-tell"; for that we can put a link in the main page to your project (assuming you create a repository on github to host it).

If there's a problem you're trying to work through, please open a new issue so we can discuss it. Github issues are supposed to be focused on a particular issue; this issue is turning into a reddit thread.

So there is a little more delay than one would have with a loopback test.

In my experience, using any Serial-type objects will significantly slow down the application (despite what the baud rate is set to). I do my best to avoid Serial interactivity.

To work around, I pasted the sketch code into this email.

Please refrain from doing that in the future because:

not all emails (more specifically email apps) use the same UTF codeset that github would expect/prefer

I cannot edit the resulting post to use syntax highlighting

I cannot quote a snippet from your email in my reply because of different line endings

it makes the thread VERY long, thus harder to traverse

some lines seem to be truncated or wrapped incorrectly, although this may have been related to your copy-n-paste attempt.

If you're going to use github to share code, then use github.com (the website) or git bash for more serious users.

The email interactions are secondary and meant for feed subscription notifications (like RSS feeds).

Github is not a social media platform, and the website's interactions have been vastly improved over the last few years.

Sorry if this is too blunt, but I have had to explain this more than once (especially in this thread). And it is always toward people that don't know/understand github better.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24/issues/811#issuecomment-989368120, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYFHIECKRCEBC466PLWVUTUP763ZANCNFSM5JDG7GGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

nRF24 / RF24

RF24 class docs page gives a 404 error #811

include

include "RF24.h"

define uchar uint8_t

define PAYLOAD_SIZE 8

define HOST_TX_PERIOD 20

define PIN_RADIO_CE 9 // RX/TX pin

define PIN_RADIO_CSN 10 // SPI chip select

define RX_TIMEOUT 100

define RADIO_ID_SELF 1

define RADIO_ID_MCU 0

define RADIO_DATA_HOST 0

define RADIO_DATA_SLAVE 1

ifdef DEBUG

endif

ifdef DEBUG

endif

ifdef DEBUG

else

endif

ifdef DEBUG

endif

ifdef DEBUG

endif

If there's a problem you're trying to work through, please open a new issue so we can discuss it. Github issues are supposed to be focused on a particular issue; this issue is turning into a reddit thread.