Problem with setting PA_LEVEL at start of Mesh

[TMRh20]

So this one has been bugging me for a while, the problem is that

1. There is no way to set the PA Level in the RF24Mesh begin() function
2. But RF24Mesh calls radio.begin() in that function which resets the PA Level to RF24_PA_MAX
   

   RF24Mesh/RF24Mesh.cpp

   Lines 26 to 36 in 7827e87

   	bool ESBMesh<network_t, radio_t>::begin(uint8_t channel, rf24_datarate_e data_rate, uint32_t timeout)
   	{
   	//delay(1); // Found problems w/SPIDEV & ncurses. Without this, getch() returns a stream of garbage
   	if (meshStarted) {
   	radio.stopListening();
   	}
   	meshStarted = true;
   	if (!radio.begin())
   	return 0;
   	radio.setChannel(channel);
   	radio.setDataRate(data_rate);

In the examples for example, the PA Level is set prior to calling mesh.begin(), but this will just be undone by the call to radio.begin() within mesh.begin()

RF24Mesh/examples/RF24Mesh_Example/RF24Mesh_Example.ino

Lines 49 to 69 in 7827e87

	// Set the PA Level to MIN and disable LNA for testing & power supply related issues
	radio.begin();
	radio.setPALevel(RF24_PA_MIN, 0);
	// Connect to the mesh
	Serial.println(F("Connecting to the mesh..."));
	if (!mesh.begin()) {
	if (radio.isChipConnected()) {
	do {
	// mesh.renewAddress() will return MESH_DEFAULT_ADDRESS on failure to connect
	Serial.println(F("Could not connect to network.\nConnecting to the mesh..."));
	} while (mesh.renewAddress() == MESH_DEFAULT_ADDRESS);
	} else {
	Serial.println(F("Radio hardware not responding."));
	while (1) {
	// hold in an infinite loop
	}
	}
	}
	}

I see one of 3 scenarios:

1. Add to the RF24Meshbegin() function, so it can set the PA Level after calling radio.begin()
2. Remove radio.begin() from RF24Mesh. This adds a some more complications, as it essentially changes the API, requiring users to call radio.begin() prior to every mesh.begin() call.
3. Leave as is, users can set the PA Level after calling mesh.begin()

I kind of prefer option 1, but would prefer option 2 if it wasn't breaking existing code.

If we choose option one, should the default be PA_MIN or PA_MAX ?

[2bndy5]

I prefer option 2 since it is consistent with using RF24Network::begin(). There's also a deprecated RF24Network::begin(uint8_t _channel, uint16_t _node_address) which I neglected to remove when releasing v2.0. So, I think we're a bit overdue for some breaking changes.

I seem to remember a rejected PR (#210) about this that instigated changing RF24::begin() so that the PA level was not altered every time it was called. Looking at RF24::_init_radio(), I see nRF24/RF24@8ad2886 in the git blame.

[TMRh20]

Hmm, I had a feeling you'd prefer option 2 😆

I didn't realize this was fixed at the RF24 level. I guess the change isn't really required then?

[2bndy5]

I guess the change isn't really required then?

At a glance, no. Did you recently have some troubling experience that you attributed to this?

[TMRh20]

Heh, the troubling experience was always adjusting my code to set the PALevel AFTER starting the mesh and again if mesh.begin() was called, which I see is not necessary anymore.

[2bndy5]

I was suspecting an ebyte module; they don't seem to respect the user-specified PA level.