Hi Peekay
After a bit of testing it seems that the receiver is only picking up signals from within 1 metre despite using the high quality part (I get 15 metre range through walls on arduino nano with bob tidey’s library even with the cheap parts). I am trying to work out what is different between lawrie’s and bob’s libraries, I suspect it is something to do with timing as you mentioned early in this discussion that hardware timers would make bob’s library difficult to port. I will plod on and try to find the answer, today has introduced me to bit shifting and many other things. Working full time on deadlines does not help with the Arduino addiction but without the money I would not be able to afford loads of spark cores and level shifters.
@bevangg, it would be cool to test the Lawrie library on the Nano as a reference. That way, we know if its a Spark vs Arduino thing. I also wonder if the wifi causes interference.
The Tidey library IS more difficult to port but not impossible. I can remove the EEPROM stuff and use the IntervalTimer library. It will just take longer.
Any thoughts?
Hi peekay
Ok, I understand. I will reprogram a nano with lawrie’s library and see how it performs.
I will post when done.
Clearly interference and connection quality and length are issues in such a project hence how I have wired it.
As for Bob’s library it does just work. However the EEPROM stuff is not really applicable or necessary for anything that I have coded so could easily be shelved or commented out, I “pair” manually through code using the serial monitor to detect and save signal codes.
So my thoughts are that even though we have got this far with Lawrie’s library it may be worth re-assessing whether it would be better to port Bob’s as it is far more usable with cheap hardware. I spent a lot of time comparing the libraries to test my timing theory but found that they use totally different logic.
I really appreciate your help so far and would like to send you the following items as a gift to thank you primarily and hopefully to inspire you to port Bob’s library:
a spark core black, 2 x 74hc4050 logic level shifters, a nano atmega328 16mhz , 2 x cheap pair 433mhz chips (I will solder aerials on for you), 1 x geetech pair 433mhz chips (same as with aerials) , 5 x 2N7000 mosfets and 10 x 10k resistors (all brand new and unused).
Then you can try the fruit of your work yourself. I have got everything except for the geetech radios and the mosfets, which I should have in 3 and 20 days respectively, and could post it to you tomorrow. If you are interested let me know and I will send you all the stuff that I have got already and the other bits when I get them.
Just to clarify I do not expect you to do anything for these parts, you have helped me greatly already and this is a thank-you. Address?(and full name!)
Best regards
@bevang, you are incredibly generous and I very much appreciate it 
I will respond to your offer once we have ported one of the libraries and get solid performance out of it. So, I will work on porting the Tidey library while you do the Arduino-Lawrie tests. 
Hi peekay. Sounds good to me. I will post results asap.
@bevangg, I ported the Tidey library but it needs testing. I added a new function to my IntervalTimer library just for this! I think I got everything but of course, it needs testing. I will be testing the added IntervalTimer functionality on my end, though I am pretty sure it will work fine.
So, here is the Tidey library on my github. Hopefully, it will work fine the first time (Yeah, right!) 
I look forward to seeing your results on the Lawrie tests.
Hi peekay
I tried lawrie’s library and it had relatively poor reception (half the range of bob’s library) even with the quality receiver and did not work at all with the cheap one. I have however tested your Tidey library and it did work first time! The range is better than it ever has been before and it works with the cheap module but with a third of the range. It seems to transmit fine without a level up-shifter but I will not use it too much until I get those bits, it would be nice to get through the first week without bricking a spark. It is tougher than I imagined, it withstood several minutes at 9 volts when I got a wire wrong. One observation is that the Vin to ground when on usb is 4.7 volts. These radios have to have as close to 5 volts as possible so I have had to add a L7805 on a 9 volt supply for it to work properly (that’s where the wire got misplaced). The nano VIN on usb is 4.85 volts and it works ok but not perfectly.
So thanks, brilliant work! Nearly there. The next challenge is timing, I was using the Time and TimeAlarm libraries but they will not compile. I will look at your spark interval timer, sounds like it could help. Thanks again for the help, pm me on bevangg@googlemail.com, I will send you those bits.
Best regards
@bevangg, I am SO glad the Tidey library works! I will be doing a pull request for the changes I made to the IntervalTimer library (too funny, a pull request to myself!) cause I think this will be useful for other Arduino ports.
The voltage on Vin is a bit lower due to a diode drop from Vusb. When I want dead-on 5v or 3.3v to power the core and peripherals, I will use a linear or buck (switching) regulator like what you do. The only catch with a 7805 using a 9v battery is the “wasted” power (3V x current). I often use Polulu or similar step-down regulators due to their efficiency and ease of use.
@bko did some amazing work on the original NTP Time library which has largely been replaced by the core firmware Time and cloud Spark.timeSync functions now. With this functionality, it is most likely possible to create a TimeAlarms library for the Spark.
Please keep sharing your project for other members to benefit from!
Hi All,
I have been porting TimeAlarms and talking about in this other thread.
I have it working but only for time zone zero (i.e. GMT). I have a little bit of work to finish it up and get it out.
@bko, you are the man! Oh, and I forgot to tell you how amazing you were (are) when the Spark Team and Elites were away. Dude, this forum would NOT be the same without you
1 Like
Hi peekay
I am afraid to say that upon further testing this weekend there is a problem. Everything seems to work ok initially but then things become random. I initially thought that it was to do with the signal to the transmitter at 3.3 volts. But it turns out that I get the same issue after modifying a sketch using your modified library on known working ATMega328 hardware (which then works as expected when compiled with the original Tidey library). I notice that you have included an ndef to detect the spark /arduino throughout the libraries and that must work or I would get no output.
I suspect it could be as simple as a formatting problem, otherwise it would not affect both boards. It also suggests that your library is working ok with timing, fundamentally, to work at all. I have pored over the library and there is nothing obvious but what would I know?
Regards
@bevangg, interesting. So the modified libary “fails” on both the Spark and the Arduino. That is a good start. I will take a look and get back to you later. Thanks for the feedback!
Hi peekay
Not quite fails. It works for the first two transmissions (not sure about that exactly) and then works at random. It seems to be trying to work but not quite getting there. The interesting fact is that it does exactly the same with the old arduino sketches, hence why I suspect it is something very minor in formatting as you have not modified the original code at all by using the ndef spark define. BTW I am intrigued by the level of C that you work at and aspire to one day have at least half of your knowledge, I had no idea that you were who you are and apologize if I insulted you by offering you a spark etc. Could you point me in the direction of some relevant learning resources?
Regards
@bevangg, you have not nor will you ever insult me with your kindness! Learning C++ is part playing, part reading. A good reading list can be found here:
Can I ask you to run the original (not the one I published) Arduino code (on an Arduino of course) to see if you get the same behavior? There are two reasons why “my” version may not be working. First, I missed something (Doh!). Second, the size of different types (int, double, float, etc) is different on the Spark than an Arduino. This often causes problems when porting code. I will look for both possibilities.
Hi peekay
The original tidey library and examples seems to work with no issue on an arduino. I have an in-service unit controlling the lights and alarm system. I modified the sketch for it on the weekend and noticed that it started to act strangely. I realised that I had moved the original libraries and therefore it was compiling with your modified library. I was a bit confused because I noticed that you had made allowance for the old code to work. I renamed the old library and changed all code references to it, recompiled and flashed and it worked again.
Thanks for the link, I will try to find time to do some reading.
Regards
@bevangg, I went through the code and cleaned up some of the compile logic and variable types. The udpate is on my github. Give it a shot on both the Arduino and Spark to see if you get better results.
Hi peekay
I have tried the new code. I am afraid that on the spark it receives fine but does not transmit, on the arduino it does neither.
I had to comment out #include “application.h” on line 6 of the headers for it to compile for the arduino.
I reckon / hope it is something minor!
Regards
@bevangg, so it’s the transmit which is based on the new timer code. That is a start! I can’t figure out, however, why it would not work on the arduino because of the conditional compile codes. I’m on it!
Hi peekay
Yes, it is the transmit that is based on the new code but the latest iteration has nobbled the receive, in which there must be a clue. I have pored over your work for hours trying to find out where the issue is and now have a very basic understanding of the changes that you have made. I cannot however work out why it is not working at all now but strongly suspect that it could be a simple formatting issue ( I also noticed that in places in the LwTx.cpp file there were references to D2 as the transmit default pin when in fact D2 is assigned to receive. Changing that to D3 made no difference.)
Your first version did actually successfully transmit the first output from the spark core, but then went haywire, and did exactly the same on the arduino. Are there any clues in these observations? I have had similar issues programming in C# where a method closing statement “finds itself” in the wrong place (with the help of asp) and it sometimes took weeks to find the problem. Let’s not even start on microsoft and ASP.not! The conditional compile codes must work or the sketches would not compile. Hence why I am convinced it is something silly.
Regards
@bevangg, I will change the default pins for transmit and I agree it is most likely something stupid. I will be looking at it later.