There are several Manchester Coding libraries for Arduino wireless transfer (See http://tinyurl.com/jh95cju), I have gotten two of them to work satisfactorily for communicating a single byte of data. Both the “Mchr3k” library “http://mchr3k.github.io/arduino-libs-manchester/” and cano64’s library “https://github.com/cano64/ManchesterRF” worked for singly byte transfers but I needed more than one byte. The libraries of both Mchr3k and cano64 claim support array transfer but I could never get cano64’s to work. However, I was successful with Mchr3k’s transmitArray() and beginReceiveArray().
void transmitArray(uint8_t numBytes, uint8_t *data);
void beginReceiveArray(uint8_t maxBytes, uint8_t *data);
Getting Mchr3k’s code to work was a bit exasperating but ultimately successful. Mchr3k’s minimal documentation is focused on the single byte transfer. Array transfer is mostly ignored in the documentation. As a result, it was not obvious, to me at least, that the first byte in the array MUST be the array size. I had incorrectly expected the array size to be internally added and stripped such that the library would deliver an unmolested data array. I didn’t want to store the array size in my array but it was unavoidable. This was NOT the case I eventually discovered that the first byte in the array MUST be set to the array size by the coder and Bingo – it started working. Before I discovered this, the first byte of my array just happened to be a zero and that did not work at all – requesting to send zero bytes has exactly that result!
Detect And Zero Rightmost One 
Ciao! I am Giovanni Blu Mitolo. I saw you tried PJON, if you need to optimize memory footprint of PJON, set PJON_MAX_PACKET_LENGTH to the maximum packet length you use (considering overhead), PJON_MAX_PACKETS to 0 if you dont use the packet scheduler queue and PJON_INCLUDE_OS to include only the OverSampling strategy, that is the one should be used with STX882 and SRX882 see:
https://github.com/gioblu/PJON/blob/master/documentation/configuration.md
https://github.com/gioblu/PJON/tree/master/strategies/OverSampling
LikeLike
I was deterred from spending too much time on PJON because my current project’s final targets will be using attiny85 and PJON’s strategies/OverSampling README.md does not indicate support for the attiny85. I thought this odd given that the original, PJON_ASK, does indicate support for “ATtiny45/85 8Mhz”. A second problem is object size. The attiny85 only has 8k of program memory and when I compile the PJON “OverSamplingHalfDuplexNoAcknowledge” example Device1.ino it compiles to a 7,622 byte object. This is MUCH too large for an attiny85.
BTW – this is the same with PJON_MAX_PACKETS 0 and PJON_PACKET_MAX_LENGTH 1 – which is logical since device1.ino only sends a single byte.
LikeLike
Ciao celem, you can regulate both PJON_MAX_PACKETS and PJON_PACKET_MAX_LENGTH depending on your necessities. I agree, about compatibility, ATtiny85 is still not in the list because it was never being tested, although if having a decent 16mhz external clock should work fine! I was able to get many kilometers range in line of sight using a couple of nanos and PJON OverSampling with STX/SRX882
LikeLike
The real obstacle is object size. Your very simple example “OverSamplingHalfDuplexNoAcknowledge” example Device1.ino sends only a single byte yet it compiles to a 7,622 byte object. Adding defines for PJON_MAX_PACKETS 0 and PJON_PACKET_MAX_LENGTH 1 still created a 7,622 byte object. With the attiny85 having only 8k of program space I don’t see a PJON solution.
I would love to see kilometers of range as currently I experience only 44.5 meter range with Manchester.
LikeLike
#define PJON_MAX_PACKETS 1
#define PJON_PACKET_MAX_LENGTH 10
#define PJON_INCLUDE_OS true
#include \
// bus(selected device id)
PJON bus(44);
void setup() {
bus.strategy.set_pins(11, 12);
};
void loop() {
bus.send_packet(45, “B”, 1);
delay(1000);
};
Compiled for ATtiny85:
Sketch uses 4,530 bytes (55%) of program storage space. Maximum is 8,192 bytes.
Global variables use 85 bytes of dynamic memory.
LikeLike
Your posted code was missing some things, like the include file. I compiled an corrected version of what you posted before (see below) and results are:
Sketch uses 4,554 bytes (55%) of program storage space. Maximum is 8,192 bytes.
———————
#define PJON_MAX_PACKETS 1#define PJON_PACKET_MAX_LENGTH 10
#define PJON_INCLUDE_OS true
#include <PJON.h>
// bus(selected device id)
PJON bus(44);
void setup()
{
bus.strategy.set_pins(11, 12);
bus.set_synchronous_acknowledge(false);
}
void loop()
{
bus.send_packet(45, "B", 1);
delay(1000);
}
For the radio transport to consume 55% of memory is quite a lot, especially since this example is very minimal, merely repeatedly sending a byte of data. For comparison, my actual code that includes the mchr3k/arduino-libs-manchester radio library plus the DHT11 temperature/humidity library. EEPROM support and my projects code compiles to:
Sketch uses 2,728 bytes (33%) of program storage space. Maximum is 8,192 bytes.
I’m not confident that PJON, DHT11, EEPROM and my application code will viably fit into an attiny85. Now, it I could obtain kilometers of range with simple ASK radios it would be worth trying.
Did you try the same ASK hardware and application code with other protocols, such as Manchester for comparison??
LikeLike
Yes for obvious reasons “” are stripped from the original content.
Yes I have experimented with ASK modules for years, since early VirtualWire times.
Tested all available alternatives, with PJON got the maximum performance related to range and communication reliability, althought is not at all encoded as many other alternatives, so I suspect the range can be further extended.
PJON being a network protocol stack, its havier than a transport 🙂
In any case, I will consider if to make a lighter version of PJON for devices with <10kB memory. Happy tinkering
LikeLike
Wow – it is after 01:00 for you – you keep long hours.
I’d love to see a lightweight version of PJON. You’ve done an amazing job with PJON.
LikeLike
Thank you so much for your compliments
Yes I often like to work in the silence of night time 🙂
I hope to have the physical time to get it done soon, I am still working on the release of the PJON v8 and get it totally cross-compatible 🙂
LikeLike
I never tried before, but seems PJON_MAX_PACKETS can be set also to 0 getting:
Sketch uses 4,488 bytes (54%) of program storage space. Maximum is 8,192 bytes.
Global variables use 62 bytes of dynamic memory.
call bus.packet_overhead() to get the actual overhead added to information, sum the max string length you use and you have the maximum packet length you are now using, so you may reduce PJON_PACKET_MAX_LENGTH to less than 10
LikeLike