@mfalkvidd Didn't think of that... I can try changing the delay() to a sleep() and see how much that impacts the temperature...
(But I still am open to ideas to help insulate the sensor, and am now also wondering whether creating extra vent holes on both sides of the rf-nano might be a good idea, even if it means more dust can come in as well...)
In my sketches I had to define the below for the built in radio to even work:
#define MY_RF24_CE_PIN 10
#define MY_RF24_CS_PIN 9
Also, I have rf-nano's from 2 sources, the one I got from the first source (don't recall where it was from) doesn't send anything at all, according to the RasPi gateway*), the other 4 (from the 2nd source) just worked
*) the radio initializes just fine, the gateway doesn't see any messages from it at all!...
Putting the graphs next to eachother, the graphs looked similar, and after guesstimating the difference and applying that to the sensor as a correction in Domoticz, the graphs are overlapping sufficiently to explain the differences by the difference in location (one is in the center at ~1.7m height, the other on a shelf in a corner at ~2m height) and standard deviation...
I'll keep it like this for a while and will reevaluate at a week's interval.
FWIW I am actually doing the basic oversampling, while doing the timed single samples.
If it remains an issue, I could modify the code to start the sensor with reduced oversampling/accuracy setting, but for now it looks good (enough)...
Sorry for the lack of response, life's been crazy... Thanks for the reply, I have since recompiled, but need to make some add'l changes to the sensor sketches, so I want to do all of that at once before I deploy to the new channel... 
@mfalkvidd Just a quick update...
Been extremely busy, so not a lot of time, but when I run the recompiled version (channel 109) gateway and use the existing - known good - sensor sketches with the channel 109 macro declaration included, it doesn't connect at all.
When I run the "old" version of the gateway and the same sensor sketches with channel 109 commented out, it just-works...
More testing and such due I guess! 
In my sketches I had to define the below for the built in radio to even work:
#define MY_RF24_CE_PIN 10
#define MY_RF24_CS_PIN 9
Also, I have rf-nano's from 2 sources, the one I got from the first source (don't recall where it was from) doesn't send anything at all, according to the RasPi gateway*), the other 4 (from the 2nd source) just worked
*) the radio initializes just fine, the gateway doesn't see any messages from it at all!...
@mfalkvidd Just a quick update...
Been extremely busy, so not a lot of time, but when I run the recompiled version (channel 109) gateway and use the existing - known good - sensor sketches with the channel 109 macro declaration included, it doesn't connect at all.
When I run the "old" version of the gateway and the same sensor sketches with channel 109 commented out, it just-works...
More testing and such due I guess!
Sorry for the lack of response, life's been crazy... Thanks for the reply, I have since recompiled, but need to make some add'l changes to the sensor sketches, so I want to do all of that at once before I deploy to the new channel...
Just trying to figure out whether there is a switch or config file option for the channel, or whether the only option to change the channel is truly to recompile?!...
Just ran the Poor Man's scanner and channels 1-98 a a garbage mess, so I need to go >> 100, but am surprised the only option there seems to be a recompile?...
Putting the graphs next to eachother, the graphs looked similar, and after guesstimating the difference and applying that to the sensor as a correction in Domoticz, the graphs are overlapping sufficiently to explain the differences by the difference in location (one is in the center at ~1.7m height, the other on a shelf in a corner at ~2m height) and standard deviation...
I'll keep it like this for a while and will reevaluate at a week's interval.
FWIW I am actually doing the basic oversampling, while doing the timed single samples.
If it remains an issue, I could modify the code to start the sensor with reduced oversampling/accuracy setting, but for now it looks good (enough)...
The min temperature has dropped significantly since using sleep(), but still the lowest I have seen is 22.8°C, when the other sensor in the room (The central heating thermostat that speaks OpenTherm) was showing a bigger variance.
My sensors are running on the 3.3v the Arduino puts out, so no extra regulators putting out heat (ie other than the one on the Arduino board).
I designed openings and stand-offs in the lid of the enclosure for the sensors, and the rf-nano sits at the bottom of the enclosure, but atm they share the same single chamber... Thinking of drilling a few venting holes near the rf-nano to let warm air out and cool air in...
IIRC am not oversampling, just doing timed single samples, but I'd have to check that.
It's currently sampling once every 10s because the enclosure also has a BH1750 lux sensor I want to sample more frequently, and they obviously run in the same sketch... 
@mfalkvidd Didn't think of that... I can try changing the delay() to a sleep() and see how much that impacts the temperature...
(But I still am open to ideas to help insulate the sensor, and am now also wondering whether creating extra vent holes on both sides of the rf-nano might be a good idea, even if it means more dust can come in as well...)
Weird question, but has anyone dealt with thermal isolation of the BMPx8x modules?
To increase the WAF, I have one, together with a BH1750 and an rf-nano in a small, aesthetically pleasing, 3D printed custom housing. However, the temperature is stuck at 26.2°C, which I assume is due to the radiant heat from (mostly) the Arduino and the nRF24L01+
So I am looking for ways to keep the BMPx8x cooler, so it can correctly measure the temperature (and therefore also the pressure, as the warmer chip means the barometric adjustment will be off)...