The rf12mods library has:
void rf12_control(uint16_t cmd)

while the original jeelib:
uint16_t rf12_control(uint16_t cmd)

This change breaks code that uses rf12_control() to read the status register.

In the original there is a note:
/// Returns the 16-bit value returned by SPI. Probably only useful with a /// "0x0000" status poll command.

How else can one read the status register without replicating rf12_control() just for that read?

The checkin on Jun 1 (adapted changes from fixInterrupts branch) broke the RF12_COMPAT mode. Turning on RF12_COMPAT in RF12.h results in a compile failure in RF69.c:

...\jeelib\RF69.cpp: In function 'uint16_t RF69::recvDone_compat(uint8_t*)':
...\jeelib\RF69.cpp:171:27: error: lvalue required as left operand of assignment
rxfill = rf12_len = 0;
^
But rf12_len is a #define in RF12.h, you can't assign 0 to it.

I'm not entirely clear why RF69.cpp is being compiled at all, but the only change I made was to set RF12_COMPAT to 1 and that caused the compile to fail.

Hello,

I've been attempting to read data from a DHT22 sensor and the Jeelib built-in DHT calls give wrong data:

I've used the example from http://jeelabs.org/2012/04/14/reading-out-dhtxx-sensors/ and got the following data out of the board:

[dht_demo]
DHT 15 4 4 4 4 4 4 4 13 4 13 13 13 4 14 4 3 4 4 4 4 4 4 5 3 13 13 13 14 13 13 13 4 4 13 13 13 4 4 14 13
HEX 3 1 74 0 FE 73 : 73
temperature = 9
humidity = 14

Although the humidity value seemed weird, the temperature value is definitely false.

I then tried using the Adafruit DHT22 Library (living at https://github.com/adafruit/DHT-sensor-library) and get much better result:

Humidity: 36.20 %   Temperature: 25.20 *C

From looking at the code, it seems that the DHT library handles temperature a bit differently il the DHT22 case (cf https://github.com/adafruit/DHT-sensor-library/blob/master/DHT.cpp#L37 and following).

Thank you for your time :)

I am unsure if the latest changes to this branch have caused this but the pin change interrupt mechanism is now broken.

I am surprised to see that the pin change interrupt mechanism is now working fine in the main branch. Incorrect!

Hi!

I would like to know if you will change the RF12 library to support the new features of SPi library as explained here: http://www.dorkbotpdx.org/blog/paul/spi_transactions_in_arduino
This new features seems solve many problem of conflict between SPI devices.

Best regards.

When the rf module is high stressed and/or far from other nodes the checkmessagereceived return ever false and i can not send on my rf module.
But if turn off and on the device it start work again.
I've debugged carefully my sketch but it seems to be the library/hardware no responding.
There's so a way to reset the rf module without reboot the device?

rf12_encrypt(KEY) is working fine when using rf12 modules (without RF69_COMPAT). When using rfm69cw modules with RF69_COMPAT sending and receiving is working fine but the encryption is just ignored (seems to be not implemented). Any ideas?

I need help with the jeelib. It compiles fine with the rather old (abandoned?) attiny core from google code: https://code.google.com/p/arduino-tiny/

But nowadays Arduino recommends this core to be used with the Attinys:
https://github.com/damellis/attiny

This core has very nice integration for thew new Arduino-IDE-Board-Manager. Sadly, jeelib cannot be used with this core. The error generated from the most basic sketch (used with Attiny84 @8 Mhz) is:

In file included from /Users/user/Documents/Arduino/libraries/jeelib-master/JeeLib.h:17:0,
from sketch_jun22a.ino:1:
/Users/user/Documents/Arduino/libraries/jeelib-master/Ports.h:713:49: error: 'Serial' was not declared in this scope
InputParser (byte size, Commands_, Stream& =Serial);
^
/Users/user/Documents/Arduino/libraries/jeelib-master/Ports.h:714:60: error: 'Serial' was not declared in this scope
InputParser (byte_ buf, byte size, Commands*, Stream& =Serial);

How can I fix the compilation problems?

I'm not good enough at tracking issues and following up. One excuse I have is that there are too many loose ends in too many places on the web.

So I've started up yet another issue tracker at http://jeelabs.net/projects/development ...

The difference: it's a single spot, and has good support for tagging, adjusting, responding, and referring to issues, which will make my life easier. Not necessarily great for everyone, but the forums at http://jeelabs.net/projects/cafe/boards remain the best place to discuss, submit, and track everything JeeQuestion'ish (the forums require registration - blame it on the spammers).

This area and the EtherCard library are the only ones on GitHub with issues still enabled. I intend to copy over the essence of the main ones, and then at some point close these down.

Pull requests with fixes, patches, and enhancements for the projects on GitHub remain enabled, and are always welcome.

....Or do I need the JeeNodes Board?

to use jeelib with an attiny45 and arduino-tiny-0100-0013, we would need defines for AVR_ATtiny45 alongside tiny44, 84 and 85. see files: Ports.cpp, Ports.h, PortsLCD.cpp, PortsSHT11.cpp, PortsSHT11.h, RF12.cpp

When I try to compile the RF12demo on OS X the compilation fails with:

RF12demo:57: error: 'void displayVersion(uint8_t)' was declared 'extern' and later 'static'
RF12demo:66: error: previous declaration of 'void displayVersion(uint8_t)'

I'll post a pull request to fix it.

you must include license text for MIT license

OK, its just a start as I have no idea where its going....;)
If we update this top item, we can at least keep the milestones visible at top of thread and further discussion can support the RoadMap. Please keep side-discussions somewhere else so this thread stays concise.

About: To discuss and identify some 'roadmap/milestone' items for the RF12 specific parts of the jeelib library - feel free to clarify the task lists until we reach a good point.

RF12 Versions

• clarify versions for driver / utilities (and be able to retrieve from github)

One we know starting point we can agree a new release version
i.e RF12Driver next release will be at v3
RFDemo next release at v12

The next agreed release will have??:

RF12 Config

• New EEPROM config structure
• New config string reported (format: ???????????????)

RF12 Tuning

• Short Writeup.
• Core Tuning features added to Driver.
• Core Tuning features added to RF12Demo and support scripts

RF12 Node Discovery

• Short Writeup
• ??

RF12 Remote script uploading

• Short Writeup
• ??

RF12 Feature Selection (so smaller cores like T84 can optionally include)

• Feature 1 (all cores)
• Feature 2 (excluded on T84 by default)
• Feature 3 (not supported on T84)

etc - I'll come back and tidy this up in a few hours

Verifying "test1.io" sketch (dated 2013-02-02) fails using Arduino 1.6.6 (downloaded 2015-11-30). Looks like the checks have become more picky. :-( Removing 'static' from line 11 allows the sketch to compile.

Error messages:

Arduino: 1.6.6 (Linux), Board: "Arduino/Genuino Uno"

/tmp/arduino_3632c65f10886781221b5da43b787a25/test1.ino: In function 'void led(bool)':
test1:11: error: 'void led(bool)' was declared 'extern' and later 'static' [-fpermissive]
static void led (bool on) {
^
test1:11: error: previous declaration of 'void led(bool)' [-fpermissive]
static void led (bool on) {
^
exit status 1
'void led(bool)' was declared 'extern' and later 'static' [-fpermissive]

It may be possible to discard an incoming packet if canSend gets called immediately after IRQ_ENABLE in the interrupt handler below.

void RF69::interrupt_compat () {
if (rxstate == TXRECV) {
// The following line attempts to stop further interrupts
writeReg(REG_DIOMAPPING1, 0x40); // Interrupt on PayloadReady
rssi = readReg(REG_RSSIVALUE);
IRQ_ENABLE; // allow nested interrupts from here on
.
.
.
.rest of interrupt handler.

There appears to be an opportunity to use rf12_sleep while there is something pending such that coming out of rf12_sleep has missed an interrupt.

see http://jeelabs.net/boards/7/topics/1083

see discussion at http://openenergymonitor.org/emon/node/1051?page=3

Hello!

I've just installed the script on a atmega328 to relay a EmonTX (openenergymonitoring.org) because it is out of reach from the RaspberryPI that is my base station.
For one client it works, but shouldn't it be for two or more clients too?

My configuration:
network group 79 on Raspberry and all devices
network group 80 for the one (or more) clients that are out of reach from the Raspberry
input group 80, nodeID 30, output group 79, nodeID 1 on relay, MULTI=0, ACK=1 (or 0, both works in my setup).

With this configuration I get the 3 values from the EmonTX to the Raspberry, but they arrive with nodeID 1, not with the nodeID of the EmonTX in group 80 as expected.

When I tried to relay a second EmonTX with 8 measurement values I only received 8 in total on the Raspberry. It looks like value 4-8 are from the second EmonTX and value 1-3 seem to be from the first EmonTX but sometimes overwritten from the second EmonTX.
I tried all combinations of MULTI and ACK but it doesn't help.

Any ideas to solve this problem and to get two or more clients relayed, maybe also with the source nodeIDs?

best regards
Juergen Brenner

see discussion at http://openenergymonitor.org/emon/node/1051?page=3

All,

Been away a while - again!!
I see lots small changes in RF12, Is there a RoadMap anywhere:

I just quickly scrolled through and sort of picked out the following:

JNu - I can see some #defines to help keep code succinct for this little uC, but code base is still growing. My assumption would be that many RF12Demo functions could be made optional and #defined out for JNu by default, making it an opt-in for that uC.
At moment looks like some functionality is hard-opted out rather than flexibly excluded.
Why am I bothered - well my TRV control project is mainly ATTiny84/JNu.
No big issue because most of this seems to be in RFDemo, not driver.

Tuning - looks like we have option to tune radio - specifically by tuning all 'leaf' nodes against 'central' nodes and adjusting 'leafs' - benefit looks to be more efficient power / range ratio = better power use.

Rearrangement of config string - better to re-issue back into cli as well as accommodating tuning data.

Nodes Visibility Database - looks like we allocate data matrix to keep an eye on 'leaf' nodes we have seen - perhaps related to tuning?

I'm happy to tighten up code for JNu use, but think would be best to understand current direction and thrust of changes. Could anyone elaborate on a basic RoadMap first?

--lightbulb

Using standard interrupts the rfmods branch produces an error when compiling for JeeNode Micro.

C:\Users\John\Documents\arduino-1.0.3-old\libraries\jeelib/RF12.h: At global scope:
C:\Users\John\Documents\arduino-1.0.3-old\libraries\jeelib/RF12.h:139: error: 'uint16_t rf12_control(uint16_t)' used but never defined

The problem is somewhere in rf12.cpp/h

Whilst debugging an issue with a sketch using JeeLib a couple of questions have cropped up that I wonder if you can clarify.

the first is in the title, in the comments in rf12.cpp it says (in so many words) to use sendStart immediately after canSend returns true. and the sendNow function also does exactly that. But (for example) your RF12demo example uses the following code

if (cmd && rf12_canSend()) {
        activityLed(1);

        showString(PSTR(" -> "));
        Serial.print((word) sendLen);
        showString(PSTR(" b\n"));
        byte header = cmd == 'a' ? RF12_HDR_ACK : 0;
        if (dest)
            header |= RF12_HDR_DST | dest;
        rf12_sendStart(header, stack, sendLen);
        cmd = 0;

        activityLed(0);
    }

is that ok to do so? Can anything change in the time it takes to do that stuff that might block the sendStart, or cause a conflict that might cause a perceived "lock up" that can be overcome by reinitializing the rfm like what is reported in issue #92 ?

The second question is regarding the recommendation or need to call the recvDone function "periodically" even when only using a device to send data. Is that comment still valid with the use of sendNow since that calls recvDone each time canSend returns false until a true is returned. Only if canSend always returns true first time would there be a period where revcDone isn't called when you're sending data regularly.

How often is periodically? is there any advantage to calling it at a particular time?

Is there any advantage to calling recvDone immediately before the send code block or even as part of the test to enter the send block?

And just for curiosity, why does the RF12demo not use sendNow? is it because you are avoiding blocking the main loop or does this code just pre-date that function?

Any clarification would be great, thanks.

This issue is intended to discuss new functions for the RF12 driver, and its required interfaces. issues to be discussed.

• replace rf12_control() by rf12_xfer, or remove the function at all from external interface.
• integration of OOK and "foreign FSK initializations.
• more functional interfaces like setBitRate, for example setFrequency.

Might it be possible to move some of the RFM12B configuration details from the library to the sketch. i.e.
// #define PINCHG_IRQ 1 // uncomment this to use pin-change interrupts

define RFM_IRQ 2

define SS_DDR DDRB

define SS_PORT PORTB

define SS_BIT 0

define SPI_SS 53 // PB0, pin 19

define SPI_MOSI 51 // PB2, pin 21

define SPI_MISO 50 // PB3, pin 22

define SPI_SCK 52 // PB1, pin 20

Alternatively could we have an interface to adjust the default values from the sketch?

HI,

is there a jeelib port for ESP8266 boards, they are ardiono compatible.
I a trying to compile some code based on standard jeelib but I am getting the error

/Arduino/libraries/jeelib/Ports.h:15:26: fatal error: avr/pgmspace.h: No such file or directory
#include <avr/pgmspace.h>
^
compilation terminated.

... in preparation of the 1.1 release with @tht's major update of the RF12 driver

Hi everyone,

I've made a sketch works on attiny84, and i 've tried to upload on a attiny87, no compilation errors (i've included correct pin_arduino.h, tiny core). but the attiny freeze on rf12_config().
Could you tell me if the library is compatible attiny87 ?

Maybe it's could help, the file pin_arduino.h

/*
pins_arduino.h - Pin definition functions for Arduino
Part of Arduino - http://www.arduino.cc/

Copyright (c) 2007 David A. Mellis

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General
Public License along with this library; if not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330,
Boston, MA 02111-1307 USA

$Id: wiring.h 249 2007-02-03 16:52:51Z mellis $
*/

ifndef Pins_Arduino_h

define Pins_Arduino_h

include <avr/pgmspace.h>

define NUM_DIGITAL_PINS 16

define NUM_ANALOG_INPUTS 11

define analogInputToDigitalPin(p) ((p < 8) ? 10 -(p): -1)

define digitalPinHasPWM(p) ((p) == 2 || (p) == 3 || (p) == 4 || (p) == 5)

define SS 10

define MOSI 11

define MISO 12

define SCK 13

static const uint8_t SDA = 4;
static const uint8_t SCL = 6;

//Ax constants cannot be used for digitalRead/digitalWrite/analogWrite functions, only analogRead().
static const uint8_t A0 = NUM_DIGITAL_PINS;
static const uint8_t A1 = NUM_DIGITAL_PINS+1;
static const uint8_t A2 = NUM_DIGITAL_PINS+2;
static const uint8_t A3 = NUM_DIGITAL_PINS+3;
static const uint8_t A4 = NUM_DIGITAL_PINS+4;
static const uint8_t A5 = NUM_DIGITAL_PINS+5;
static const uint8_t A6 = NUM_DIGITAL_PINS+6;
static const uint8_t A7 = NUM_DIGITAL_PINS+7;

//----------------------------------------------------------
//----------------------------------------------------------
//Core Configuration (used to be in core_build_options.h)

//If Software Serial communications doesn't work, run the TinyTuner sketch provided with the core to give you a calibrated OSCCAL value.
//Change the value here with the tuned value. By default this option uses the default value which the compiler will optimise out.

define TUNED_OSCCAL_VALUE OSCCAL

//e.g
//#define TUNED_OSCCAL_VALUE 0x57

//Choosing not to initialise saves power and flash. 1 = initialise.

define INITIALIZE_ANALOG_TO_DIGITAL_CONVERTER 1

define INITIALIZE_SECONDARY_TIMERS 0

define TIMER_TO_USE_FOR_MILLIS 0

define HAVE_BOOTLOADER 1

/*
Where to put the software serial? (Arduino Digital pin numbers)
*/
//WARNING, if using software, TX is on AIN0, RX is on AIN1. Comparator is favoured to use its interrupt for the RX pin.

define USE_SOFTWARE_SERIAL 0

//Please define the port on which the analog comparator is found.

define ANALOG_COMP_DDR DDRA

define ANALOG_COMP_PORT PORTA

define ANALOG_COMP_PIN PINA

define ANALOG_COMP_AIN0_BIT 6

define ANALOG_COMP_AIN1_BIT 7

/*
Analog reference bit masks.
*/
// VCC used as analog reference, disconnected from PA0 (AREF)

define DEFAULT (0)

// External voltage reference at PA0 (AREF) pin, internal reference turned off

define EXTERNAL (1)

// Internal 1.1V voltage reference

define INTERNAL (2)

//----------------------------------------------------------
//----------------------------------------------------------
//----------------------------------------------------------
//----------------------------------------------------------

define digitalPinToPCICR(p) (((p) >= 0 && (p) <= 10) ? (&GIMSK) : ((uint8_t *)NULL))

define digitalPinToPCICRbit(p) (((p) >= 3 && (p) <= 10) ? 4 : 5)

define digitalPinToPCMSK(p) (((p) >= 3 && (p) <= 10) ? (&PCMSK0) : (((p) >= 0 && (p) <= 2) ? (&PCMSK1) : ((uint8_t *)NULL)))

define digitalPinToPCMSKbit(p) (((p) >= 3 && (p) <= 10) ? (10 - (p)) : (p))

ifdef ARDUINO_MAIN

// On the Arduino board, digital pins are also used
// for the analog output (software PWM). Analog input
// pins are a separate set.
//#define SS 10
//#define MOSI 11
//#define MISO 12
//#define SCK 13
// +-/-+
// RX (D 0) PA0 1| |20 PB0 (D 4)
// TX (D 1) PA1 2| |19 PB1 (D 5)
// (D 12) PA2 3| |18 PB2 (D 6)
// (D 3) PA3 4| |17 PB3 (D 7)
// AVCC 5| |16 GND
// AGND 6| |15 VCC
// INT1 (D 11) PA4 7| |14 PB4 (D 8)
// (D 13) PA5 8| |13 PB5 (D 9)
// (D 10) PA6 9| |12 PB6 (D 2)* INT0
// (D 14) PA7 10| |11 PB7 (D 15)
// +----+
//
// * indicates PWM pin.

// these arrays map port names (e.g. port B) to the
// appropriate addresses for various functions (e.g. reading
// and writing)
const uint16_t PROGMEM port_to_mode_PGM[] =
{
NOT_A_PORT,
(uint16_t)&DDRA,
(uint16_t)&DDRB,
};

const uint16_t PROGMEM port_to_output_PGM[] =
{
NOT_A_PORT,
(uint16_t)&PORTA,
(uint16_t)&PORTB,
};

const uint16_t PROGMEM port_to_input_PGM[] =
{
NOT_A_PORT,
(uint16_t)&PINA,
(uint16_t)&PINB,
};

const uint8_t PROGMEM digital_pin_to_port_PGM[] =
{
PA, /* 0 /
PA,
PB, / 2 /
PA, / 3 /
PB, / 4 /
PB,
PB,
PB,
PB,
PB,
PA, / 10 /
PA,
PA,
PA,
PA,
PB, / 15 */
};

const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] =
{
_BV(0), /* 0 _/
_BV(1),
BV(6), / 2 _/
BV(3), / 3 _/
BV(0), / 4 _/
_BV(1),
_BV(2),
_BV(3),
_BV(4),
_BV(5),
BV(6), / 10 _/
_BV(4),
_BV(2),
_BV(5),
_BV(7),
BV(7), / 15 */
};

const uint8_t PROGMEM digital_pin_to_timer_PGM[] =
{
NOT_ON_TIMER,
NOT_ON_TIMER,
TIMER1A,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
TIMER1B,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
NOT_ON_TIMER,
};

endif

endif

//Old code, just here for temporary backup until I decide it is not needed.
//WARNING, if using software, RX must be on a pin which has a Pin change interrupt <= 7 (e.g. PCINT6, or PCINT1, but not PCINT8)
/*#define USE_SOFTWARE_SERIAL 1
//These are set to match Optiboot pins.

define SOFTWARE_SERIAL_PORT PORTB

define SOFTWARE_SERIAL_TX 0

define SOFTWARE_SERIAL_PIN PINB

define SOFTWARE_SERIAL_RX 1*/

Thanks for your help

Hi all,

I'm trying to repair / flash the bootloader of my JeeNode USB v3 as explained in this post http://jeelabs.org/2011/05/29/summary-of-isp-options/

However, when I load the sketch in de Arduino 1.0rc IDE and compile, I get the following error:

C:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100 -IC:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\arduino\cores\arduino -IC:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\arduino\variants\standard C:\Users\Janus\AppData\Local\Temp\build8909196006120046362.tmp\isp_repair2.cpp -oC:\Users\Janus\AppData\Local\Temp\build8909196006120046362.tmp\isp_repair2.cpp.o In file included from C:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\arduino\cores\arduino/Arduino.h:204, from isp_repair2.cpp:101: C:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\arduino\variants\standard/pins_arduino.h:41: error: expected unqualified-id before numeric constant C:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\arduino\variants\standard/pins_arduino.h:42: error: expected unqualified-id before numeric constant C:\Users\Janus\Documents\Java\workspaces\HomeCenter\build\arduino-1.0-rc1\hardware\arduino\variants\standard/pins_arduino.h:43: error: expected unqualified-id before numeric constant

Am I missing something?

Regards, Jan

Decide how to deal with documentation sets which may gradually diverge between 1.0 and 1.1 - perhaps just keep a tarball of the older releases once new releases are out?

Could someone please check if everything is ok with the ACK-function.
My usecase looks like this:

Today i updated to the latest Arduino-Software and downloaded the latest jeelib.
I send a package that wants an ACK and use following code in the receiver-node:

if ((rf12_recvDone())&&(rf12_crc == 0)) {
..............
rf12_sendStart(RF12_ACK_REPLY, 0, 0);
rf12_sendWait(0);
}
On the "old" Arduino1 this was ok, and the ACK was received by the sender-node - now it is missing. I tried normal messages without problems and then even isolated the problem by trying things like "canSend" before and sending (and receiving) normal packages before or after the regular ACKs.

Can anyone reproduce the problem?

Suspect a problem in old code.

Currently, rf12_config() reports something like:

[RF12demo.10] _ i31 g42 @ 868 MHz

The values give an idea of the current configuration, as restored from EEPROM. They also get used by HouseMon, which triggers on a line of this form to extract the settings.

It would be better to change the format to something like:

[RF12demo.10] 31i 42g 8b

Because then this output can be pasted back as commands to reset the node if its configuration is accidentally changed, or if the same settings need to be used elsewhere.

This will become even more useful when frequency offset tuning is added to the RF12 driver and RF12demo (see the RF12demo branch).

Changes should be such that the size of rf12_config() only increases as little as possible (since the RF12 driver still needs to work in the smallest possible µC context). By having this logic generated in RF12demo (as it is now) and stored as text string as before in EEPROM, that can indeed remain the case.

With the changes in progress on the rf12demo branch, it would be nice to be able to automatically seek the best frequency to receive a specific node.

Perhaps as follows:

• add a <nnn> u command (tUne)
• when enabled, it starts listening only to packets from node nnn
• use some sort of gradual adjustment of the reception frequency
• report reception signal level (for node nnn only) and current freq setting
• stop this process when 'u' is entered without arg (or maybe even automatically)

During this process, reception from other nodes will be deteriorated (or maybe disabled altogether). Once the best offset has been found, the opposite offset should be added to the remote configuration, as compensation.

I think there is a problem with short non jeenode packets passing into the driver. When rf12_len contains a large value but the actual packet length is short, around 5 bytes then TXRECV doesn't appear to exit. This is a placeholder don't do anything on it since my testing and workaround is with RFxConsole. I think master branch will also be suffering.

I thought we had fixed this once before. However, reusing a Jeelink with non-standard eeprom contents and loading master branch RF12demo.ino does not yield a working Jeelink.

The folders are getting too long and confusing. Split in things like "ISP", "Plugs", etc.

This will affect the documentation, and breaks the existing weblog links to sketches. Probably best to just go ahead and update all those broken links?

Hm... might also break some links on Redmine, maybe a simple search will find them, i.e. "Examples/Ports/", etc.

Hi Guys
During this "Data loss due to RF packets getting corrupted" discussion on the openenergymonitor forum, I learn't about the "// FIXME doesn't seem to work, nothing comes in but noise for group 0" line in rf69.cpp.

Is there a fix planned for this?

I have extended a rf12demo sketch to have a "trace_mode" to help troubleshoot rfm network issues that is unable to fully function due to not getting a full promiscuous mode of operation.

It simply uses rf12_recvDone() on a regular timebase (0.1s to 2.55s) to refresh the rssi value and from that a trace is output to a serial console.
the additional code is wrapped in "#if RF69_COMPAT"s and is dormant in normal running, I've used "y" as the command and the preceding value defines the timebase. "0y" is off(default) and 10y pauses normal packet processing and outputs the rssi based trace to serial every 0.1s.

I have seen in the RFconsole there is a "fourByteSync" used in place of a "fiveByteSync" to exclude the group id from the signature comparison, Having looked into this myself I'm afraid it's beyond my ability and it looks like any fix would need to be in the lib rather than the sketch.

Paul

RFxConsole branch:
\ i28* g212 @ 868 MHz o1700 q1 c1 tx80 rxBC

OK 252 227 201 95 204 235 248 8 49 193 62 224 133 18 127 87 133 224 10:22:54:744] 246 251 194 158 160 5 164 80 96 0 5 126 26 50 140 9 96 239 79 50 12110:22:54:748] 43 223 104 13 240 191 202 40 192 23 186 166 85 204 238 (93dB)
10:22:54:748] -> ack i28