Author Topic: what I would like to see ....  (Read 16447 times)

oric_dan

  • Jr. Member
  • **
  • Posts: 64
what I would like to see ....
« on: January 06, 2016, 10:47:47 PM »
[maybe this is available and I haven't seen it]

.... is an easy way to connect a lowpowerlabs RFMxx radio to a regular Arduino board such as an UNO, namely, something like a nice "plug-in shield" so you could forego having to stick a bunch of jumper wires into the usual Arudino female headers (and which I find to be a much less than optimal arrangement), or having to solder up a prototyping board.

Ideally, what I would like to see is a Moteino, or better yet Moteino-Mega, laid out with standard UNO form-factor female headers, and with decent 1-Amp voltage regulators, and the RFM radio wired on-board.

Then I could plug in an ethernet shield and connect to my router, and also an LCD shield on top of that. Then I would have a nice self-contained unit with no trailing wires that I could use as the Hub of a local RF network, and so I could easily connect the network to the internet. So, one unit altogether:

Hub Board (UNO form-factor):
--> RFMxx radio (on-board) --> other Moteinos
--> Ethernet shield (plug-in) --> router
--> LCD shield (plug-in) ~ menuing

Yes, no, maybe?
« Last Edit: January 06, 2016, 11:02:25 PM by oric_dan »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: what I would like to see ....
« Reply #1 on: January 06, 2016, 11:09:19 PM »
Nice idea. What about a Moteino-UNO with no MCU but that can take a Moteino or MoteinoMEGA (headers for both). Then you could swap between MCUs by plugging different Moteinos if you wanted I guess... and for MEGA the extra headers would be on a side.
That would require a bit more soldering to get headers into the shield and into your Moteino, and would require 2 items (the shield itself and the Moteino). But it would be cheaper than with MCU onboard. A possible issue would be if the Moteino in the middle of the board is sticking too high up and could touch any stacked board on top.

The problem with atmega1284 ($8.4) is it's an expensive chip compared to atmega328 ($3.58), more than double. To factor that into a product you have to multiply it by a factor that will allow for some margin if you don't want to work for free. If you do that, you gather the wrath of the ESP8266 and chinese ArduinoMini fans who think everything in the world should cost no more than $3. So how do you make a product (product means business, ie profit) that is cheap and flexible and easy to use/make/test/distribute?

Anyway it's something I will consider, but my current focus is on another few things. But let's keep the iron hot and juggle some ideas of what features the ideal Moteino-UNO-board would be.

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #2 on: January 07, 2016, 12:00:31 AM »
Felix, you're 1000% correct - anymore, it's a problem to try and compete with the Shenzhen boys, given costs of production [and shipping] in america. I like your idea of having layout for both 328 and 1284 DIP chips, and then someone could plug in whichever chip they like, although the dual routing might be a pitn with a 2-layer pcb.

OTOH, if you were to leave off the FTDI chip and use an adapter instead, as you do at present, I should think you could do "individual" 328 and 1284 pcbs with UNO form-factor for about the same cost as your current Moteino and -Mega boards. The only real difference would be the cost of a bit more real estate. I've always liked the UNO form-factor, as it's small and you can use all the standard Arduino shields. It just needs better v.regs than the std Arduino boards use. Plus it would be really nice to have everything self-contained for use as a central network Hub that could connect directly to a router.

I designed my own 328 and 1284 pcbs a couple of years ago, and which I use for all of my projects. I use 3-row headers, since most of my projects are robots. The board below, built in 2013, shows an RN-XV plugged in, but anymore I've gone away from the 2.4G band. I had initially thought about selling these things, but then Shenzhen exploded.

Height of the 1284 DIP chip sticking up is not a problem, in regards inference with plugin shields. It's the same as on a regular UNO board with DIP28, but you'd not have any problem if you used your current SMT chips.

Just some thoughts.

EDIT: oh yeah, you would need to make sure the RFM radio were located somewheres so the antenna wouldn't conflict with plugin shields, but then I would definitely put a reverse-SMA connector on the pcb. BTW, the DIP8 socket allows me to plug in an SPI eeprom or 128KB RAM chip.
« Last Edit: January 07, 2016, 12:11:54 AM by oric_dan »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: what I would like to see ....
« Reply #3 on: January 07, 2016, 08:12:00 AM »
Good ideas, nice pcb you got there!
The more I think about it the more I am inclined to lean towards putting everything on the board, including MCU. I would go with an atmega1284 for added memory and more GPIO. THose who want to prototype would benefit from a middle way to a real Arduino MEGA, more expensive but net superior to a UNO.
One thing I can't quite settle or see the whole picture is the voltage, I feel I am missing something. I could run the whole thing at 5V then interface 3.3v to the radio and FLASH. Then people that are having issues with 3.3v could just use this board. That would break away from the Moteino 3.3v tradition though, but it could run the MCU at 20mhz, if I source yet another part just for that.

Funny thing is I designed and made some Moteino and MEGA that run at 5V, same format as the 3.3v boards, but never mass produced them. They just used resistor networs to divide voltages and talk to the radios/flash, they worked just fine.

jra

  • Jr. Member
  • **
  • Posts: 81
  • Country: us
Re: what I would like to see ....
« Reply #4 on: January 07, 2016, 12:20:06 PM »
@oric_dan Take a look at the http://www.firebirduino.com/sb_bb_v3/.  Says it is a standard Arduino UNO R3 form factor, accepts a 328 or a 1284 and has a connector for a nRF24L01+.  Charles Hallard has designed breakout boards for a variety of RFMxx radios that use the nRF24L01 connector, see https://oshpark.com/profiles/hallard so maybe this combination would work for you.

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #5 on: January 07, 2016, 02:04:24 PM »
jra, thanks for the links. My original suggestion is something like the Sleeping Beauty, but with RFM radio layout.

Felix, a few more ideas ...
I definitely prefer the 1284, and use the board shown for most of my projects anymore. You'll notice my board does have everything on it, so it'll make a complete robot: 5/3.3V 1A v.regs, radio, extra RAM/eeprom chip, piezo, 32KHz xtal layout, Arduino female headers plus 3-row male headers, and I2C header. Sensors and servos plug right in. The 328 chips don't have enough RAM or IO pins for a decent robot.

One thing I did compromise on was to put the ICSP header is the "wrong" place, since the XBee socket and 5V regulator took up so much space. However, only the Ethernet shields use that header to my knowledge, so I have some that are hardwired to D11..D13, and I rewired others so they'd plug in. If the board had both DPAK vregs and a smaller layout for RFM radio, then the 1284 chip could be moved back, and the ICSP put in the usual place. But no issue anyways with SMT 1284 chips. And you could add a header on the right side for the extra 1284 I/O pins, as you mentioned.

Anymore I use DPAK v.regs for both 5V and 3.3V regulators on my newer boards. They are small, very cheap, and have superior heat characteristics to SOT-223/23.
http://www.digikey.com/product-detail/en/LD1117DT50TR/497-1238-6-ND/1848396

There is a jumper on the board that can switch the cpu Vcc between 5V and 3.3V. If you look "closely" at the oscillator frequency vs Vcc curves in the AVR datasheets, you'll see that at 3.3V the allowable freq shown is actually about 13.3 MHz, so using a 16 MHz xtal is only overclocking by 20%. I've never had any problem with a 16 MHz xtal and 3.3V, and many other people on the Arduino forum have done likewise. I do have voltage-dividers under the XBee radio socket for when Vcc=5V, but anymore I mostly use Vcc=3.3V anyways.

One other thing, there is plenty of room to have more than a single SOIC8 layout for SPI flash/RAM, and I would have at least 2 such layouts. Also, my boards have series-Rs for protection in all I/O lines, but they take up a lot of space. I would however include 1K series-Rs at least in the Rx,Tx lines going to the FTDI connector, so then the FTDI adapter pin voltages wouldn't be a problem.

 EDIT: I would also put a jumper on the Vin pin on the FTDI header, so it wouldn't conflict with direct power to the board.
« Last Edit: January 07, 2016, 02:29:25 PM by oric_dan »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: what I would like to see ....
« Reply #6 on: January 07, 2016, 04:57:29 PM »
oric_dan,
It really sounds like you already got everything in your board, except the radio?
If that's the case, all you'd need is a breakout for the radio with appropriate voltage buffering. Would that work?

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #7 on: January 07, 2016, 07:49:30 PM »
Yeah, I've already done that a couple of times with my Tredici-1284 board, stuck a radio on a small fiberboard using double-sided tape, and placed in the XBee area and hardwired to the SPI pins. My 2 network Hubs mentioned in the other thread do this. It helps that I have 3.3V 1A regulators on all my boards.
https://lowpowerlab.com/forum/index.php/topic,1494.0.html

However, my original intent of this thread was that I thought the Moteino world could make use of an official board coming from your shop that could be used as the "central Hub" for the rest of a Moteino network, and able to mount ethernet, LCD, and other regular shields. I would design it more like a regular UNO board, but with the 1284 chip, rather than including all the special things I have on my board. Nice 1A DPAK v.regs, an SMT cpu chip, and layouts for radio, 2/ea SOIC8s, and an extra header on the right side. It would cost little more than your Moteino-Mega to produce.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: what I would like to see ....
« Reply #8 on: January 07, 2016, 09:42:02 PM »
It would cost little more than your Moteino-Mega to produce.
I feel it could cost quite a bit more :)
Regarding the DPAK, that will be good for lots of power but there will be the crowd that will complain that it's not low power enough. We could just slap a response like it's not meant for low power but I feel like I almost agree it should be low power friendly too. What do you think about that?

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #9 on: January 07, 2016, 10:56:30 PM »
You would know better of course, but I figure the parts would be about the same as on the current Moteino-Mega, except for the additional $0.26 DPAK 5V regulator, plus 6 sqin area rather than 2 sqin. I don't know how much cost the expanded real estate would add. The Arduino female headers would jack up the cost, but pretty much everyone has those on their own anymore, and you could probably have a stripped-down option sold with no headers included, so 3X real estate would be the main added cost.

My feeling about power is that, this board would be intended as the "Hub" for a Moteino network and be located in a central location and likely be connected to the PC much of the time, so power draw would not be a big issue. You still have your low-power Moteino and -Mega boards to use for all the remote nodes. So, this board would mainly be to tie everything together as a central core, and for connection to the router, etc. Ethernet will always draw a lot of power.

My home automation system actually has 2 Hubs like this using my Tredici-1284 boards, one Hub for the in-condo RFM12 security / environmental monitoring network, and the other Hub using the RFM69 radios to connect to my robots and the SUV outside on the other side of the bldg in the carport. The RFM12s don't have enough power to make it to the SUV reliably, but work fine for inside the condo.

I use a separate Arduino Mega2560 board as a common Base Station connecting to the 2 Hubs via RS232, and have the Ethernet board and LCD on it. This seemed like a natural way to go, since I have 2 networks using 2 different radios. But for only 1 network, the Hub could have RFM radio, ethernet shield and LCD, although it would take a bit of extra coding to support all 3 via SPI.

Hmmm, it just occurred to me that the "new" Hub board could also be designed to plug in an ESP8266 wifi module for connection to the router, rather than via Ethernet. There should be plenty of room for that. So, that's high-power once again. I am equivocal about the ESP8266 modules, however, as my experience of a year ago is that they are somewhat unreliable, but maybe their firmware is better now. But it's another possibility.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #10 on: January 08, 2016, 12:17:48 AM »
@oric_dan:  Are you saying its primary purpose is to connect your PC to the Moteino(s) using ethernet/wifi?  i.e. creating a virtual serial connection?  If so, there's an easier way of doing that via wifi-only using just an ESP8266.  If you feel you also need the wired ethernet connection, then maybe Felix's Pi gateway, or perhaps even just a plain Pi that runs a bash file with a few linux commands on boot-up, would be an option you'd want to entertain.  Probably the $9 C.H.I.P. could do it as well.
« Last Edit: January 08, 2016, 01:19:51 AM by WhiteHare »

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #11 on: January 08, 2016, 02:03:21 AM »
WH, there are several possibilities. Using the RPi is one, but then that requires that one buy the Pi, and also learn to use it. My initial thought was that using an Arduino board for the Hub would be cheaper and directly inline with using the Moteino and -Mega in the first place.

The other business was just several possible connection schemes for the Hub.
- its primary use is the central point for the Moteino network.
- then, you could choose how you want to connect it to the rest of the world.
- either directly via FTDI to the PC,
- or via Ethernet shield to your router [which is how my Base Station is connected],
- or via wifi [ESP8266] to the router.
The UNO form-factor would allow any of these.

Also, my Base Station also has an LCD shield with a menuing system, so I can access it manually without having to turn on my PC at all. So, it's all standalone, and the PC needn't be turned on when I'm out of town for instance. The Base Station gets to the outside by sending Tweets and data to Xively. For that matter, the Base Station/Ethernet/Router pathway also serves webpages locally, which I can access using my Android Tablet. All of the latter software is available in Arduino-land. So I do it every which way,

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #12 on: January 08, 2016, 10:53:03 AM »
I've just never seen atmega's do very well at serving web pages.  Not enough oomph.  The web pages they can serve tend to be rudimentary, and with slow turnaround.  If you're determined to go that route, maybe consider using a Due or similar?

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #13 on: January 08, 2016, 01:32:48 PM »
WH, you're entirely correct, thanks for pointing that out. Arduinos are not the best webpage-servers in the universe, and no doubt totally miserable for hosting dynamic pages.

I am just using simple HTML pages that allow basic monitoring and simple control of the home automation system. A sample page is shown below. I can monitor things, and turn switches on and off as shown. My overall system is half-implemented at present, but the idea is it will be standalone [ie, absent the PC] and will use the Android tablet for basic remote control inside the house.

Currently, my "more powerful" processor boards use 96-MHz Teensy3.1 modules, and the picture shows the HTML software being tested on this, but it was initially developed on the Arduino. I'm pretty sure a mega1284 Hub with RFM radio and Ethernet card could handle the RF network and also serve pages such as this. For a really fancy home automation system using the RPi, there is this guy who frequents the Arduino forum.
http://www.desert-home.com/2013/09/raspberry-pi-home-automation-process.html

EDIT: another thing is, I currently have no plans to allow direct access "into" the home automation system via the web from outside, so the web stuff is minimal. It does send "out" Tweets and data to Xively, so I can monitor the condo while traveling. So, my original idea for an UNO form-factor Moteino board wasn't something on too grand a scale overall.
« Last Edit: January 08, 2016, 01:43:38 PM by oric_dan »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #14 on: January 09, 2016, 04:41:02 AM »
Quote
Arduinos are not the best webpage-servers in the universe, and no doubt totally miserable for hosting dynamic pages.

On the other hand at least with 433Mhz the Pi just causes too much interference. Costs me easily an impact of -15 in RSSI at times. I like the idea of a very light-weight gateway that only transcodes between radio and IP. Then do the heavy lifting either on a Pi or in the cloud.

Imagine smth like code bender, only you don't hook anything up to your laptop. Installs happen via wireless updates and you also develop your backend directly in the tool. All that's necessary at home is a battery of Moteino's and a tiny IP GW, possibly just a Moteino with attached ESP8266.

Joe

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #15 on: January 09, 2016, 09:00:06 AM »
I like the idea of a very light-weight gateway that only transcodes between radio and IP. Then do the heavy lifting either on a Pi or in the cloud.

Imagine smth like code bender, only you don't hook anything up to your laptop. Installs happen via wireless updates and you also develop your backend directly in the tool. All that's necessary at home is a battery of Moteino's and a tiny IP GW, possibly just a Moteino with attached ESP8266.

Joe

Yup, and it nearly already exists.  Connect your Moteino wireless gateway to an ESP8266 (I'm using an ESP13) using ESP-Link.  That creates a virtual serial link between the wireless Moteino gateway and Felix's Pi gateway (or whatever you're using).  You can continue to do wireless programming of Moteino's using msjfb's wonderful GUI tool (https://lowpowerlab.com/forum/index.php/topic,1056.0.html).  You can wirelessly reprogram the Moteino wireless gateway a little differently, using an ESP-Link tool.

That all works without a hitch.  The only part I haven't yet tried is the part I was least worried about, which is virtualizing the serial connection on the Pi itself, so that those communications are automatically routed through the ESP8266's IP address between the Pi and the Moteino wireless gateway.  I'm quite sure that part can be made to work though, because I've already been able to putty over IP with the ESP8266 and have it be the same as a direct serial connection to the Moteino wireless gateway.

[Edit:  Of course, if Felix wanted to, he could  add that capability directly to his Pi gateway code, and then it could work directly and more elegantly (similar to what msjfb did) without the need for this extra step.   To what end?  Well, if he wanted to, he could package up a liteweight gateway and add it to his store.  :)  It's all open source anyway.  Though it's really not hard to DIY, it will of course be even easier to just buy something and save the hassle, knowing that it will immediately "just work."]

[P.S.: I forgot to mention that the ESP8266 firmware is itself wirelessly programmable too.  So, literally everything in the entire chain is now wirelessly programmable.  No need to carry anything back to plug-in to your computer.  :)]
« Last Edit: January 09, 2016, 05:15:14 PM by WhiteHare »

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #16 on: January 09, 2016, 02:46:30 PM »
On the other hand at least with 433Mhz the Pi just causes too much interference. Costs me easily an impact of -15 in RSSI at times. I like the idea of a very light-weight gateway that only transcodes between radio and IP. Then do the heavy lifting either on a Pi or in the cloud.

Imagine smth like code bender, only you don't hook anything up to your laptop. Installs happen via wireless updates and you also develop your backend directly in the tool. All that's necessary at home is a battery of Moteino's and a tiny IP GW, possibly just a Moteino with attached ESP8266.

I've not tried the RPi with RFM radios, but good to know about the interference issue. Not too surprising, considering the Pis use 700-1000 MHz clocks. I wonder if there is any interference problem with putting an RFM radio and ESP8266 a few inches apart on the same Moteino gateway board, such as we've been discussing. ??

And I hope the ESP8266 firmware is a little more reliable than when I tried it a year or so ago. ?? People on the Arduino forum were having all sorts of reliability problems, crashing after running for a while, &etc.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #17 on: January 09, 2016, 05:30:03 PM »
I wonder if there is any interference problem with putting an RFM radio and ESP8266 a few inches apart on the same Moteino gateway board, such as we've been discussing. ??


That's an intersting question.  If anyone has some test code they'd like me to run that measures baseline RSSI value, or whatever, on the Moteino, I'd be happy to run it and post the results, both with and without an ESP13 turned-on nearby.  I'm not volunteering to write the test code though, even though it probably wouldn't be very hard to write.

The newer modules, including the ESP13 and ESP12, do come with metal lids soldered to ground, so maybe they throw off less noise than those that don't.  At a superficial level, the ESP13 module looks pretty much the same as the expressif module which allegedly did pass FCC.  I do wonder how much noise/harmonics RFM's are shedding, as some other Semtech module venders do use metal lids.  There is a test report posted on the HopeRF website which is positioned to mollify those potential concerns....
« Last Edit: January 09, 2016, 06:02:14 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #18 on: January 09, 2016, 05:36:31 PM »
Quote
If anyone has some test code they'd like me to run

You could just take Felix' gateway sample sketch and monitor the RSSI values it reports on the serial. Then switch on the 8266 with wifi traffic and see if anything changes.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #19 on: January 09, 2016, 05:51:07 PM »
Quote
using ESP-Link

I probably wouldn't use esp-link but write some code for the 8266 directly to talk to the radio and relay between radio/wifi. Maybe add some caching support for wireless updates if the backend runs in the cloud. Should all be fairly simple.

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #20 on: January 10, 2016, 12:44:39 AM »
Speaking of metal cover shields, I just received this board a couple of days ago, to make another stab at using the ESP8266, just to see how it works. I wanted something I could just plug into a UNO board, and not mess with those silly jumper wires hanging all over the darn place.  Note - it did take Banggood over 1-month to deliver the thing to the US.
http://www.banggood.com/ESPDuino-Development-Board-ESP-13-WiFi-UNO-R3-from-ESP8266-p-1023370.html

EDIT: sorry, this is the board I received, not the other one,
http://www.banggood.com/ESP8266-Web-Server-Port-WiFi-Expansion-Board-ESP-13-Compatible-With-Arduino-p-1008124.html
« Last Edit: January 10, 2016, 01:46:58 AM by oric_dan »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #21 on: January 10, 2016, 04:52:48 AM »
Quote
I like the idea of a very light-weight gateway that only transcodes between radio and IP.

The more I think about it the more I like it - if it works out interference wise. No question as time goes on one will want to add all kinds of radios to the mix. See recent LoRa discussions. Or I will likely add 866Mhz to keep underground wide band antenna size manageable. With this approach it becomes very simple - just add another light weight radio/wifi gateway. No need to fiddle with the Pi or it's MightyHat.

The other use case this would support: I have two scenarios which hog the radio for long periods of time: (a) listen mode wakeup bursts and (b) controlling 433mhz rf plugs (to a much lesser degree). I currently use AC based nodes that aren't that busy for this sort of stuff - like the bathroom fan controller. But for the general case it would be much nicer to just add another radio to the light weight gw and keep all nodes available at all times.

With a second radio I could use wakeup bursts much more aggressively. For example a coin cell based mote could communicate directly with another one by using the gw to relay the package using the wakeup burst mechanism or similarly I could have coin cell nodes switch ac-plugs using the gw.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #22 on: January 10, 2016, 05:11:16 AM »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #23 on: January 10, 2016, 11:47:38 AM »
Speaking of metal cover shields, I just received this board a couple of days ago, to make another stab at using the ESP8266, just to see how it works. I wanted something I could just plug into a UNO board, and not mess with those silly jumper wires hanging all over the darn place.  Note - it did take Banggood over 1-month to deliver the thing to the US.
http://www.banggood.com/ESPDuino-Development-Board-ESP-13-WiFi-UNO-R3-from-ESP8266-p-1023370.html

EDIT: sorry, this is the board I received, not the other one,
http://www.banggood.com/ESP8266-Web-Server-Port-WiFi-Expansion-Board-ESP-13-Compatible-With-Arduino-p-1008124.html

I tried the second board you linked, but I had only partial success in getting it to work with ESP-Link.  Unfortunately, I never could find a schematic for it.  IIRC, the problem I ran into with it was that it could not re-program an attached moteino.  I ditched it and just built a plain vanilla ESP13 configuration on a breadboard, using a OSH-PARK breakout board just to give  access to the castellated pins on the ESP13.  That worked just fine for POC testing, though it may prove a bit hairy as a testbed for the RF interference testing discussed above.  When time allows I'll move it over to a board where I can at least solder all the connections.

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #24 on: January 10, 2016, 03:04:09 PM »
WH, good to hear of your experience with that board. As I've mentioned, I've not played with ESP8266 for over a year, due to past unreliability experiences with those devices, and also to concentrating on the RFM radios. Also, people have found that in general there is too much latency with using wifi to control robots. You need quick turnaround responses.

However, someone who has been having luck with the ESP8266 might try it on the same Moteino board with RFM radio, and check for interference problems.
-----------

Also, I thought I would toss out one more picture, in regards ideas that might be incorporated into a possible Moteino gateway board.

I designed the board shown below a year ago, as a general "all-purpose" small RF node. I don't have a current picture of a built-up pcb, but this shows the actual top-bottom layout [bottom traces are in blue, so you're in effect looking "through" the board at the bottom, :-)]. 1.5"x2.5", mega328 DIP chip, 3-row headers for robot sensors/servos, DPAK 3.3V 1A regulator although a micro-power v.reg can be soldered in, layout for both XBee socket and also pads [in red] for RFM radios on top inbetween the XBee pads. The FTDI dongle plugs in next to the cpu.

The points I wanted to make are that I've set this up to handle all sorts of customization:
- HDR3 is a 2x8 (uncommitted) header that allows me to mount nRF2401 and ESP826 radios, 128x160 LCDs, sensors like an MPU6050 accelerometer/gyro board, etc.
- so overall, it can handle any of XBee, RN-XV, RFMxx, ESP8266, and nRF2401 radios.
- SOIC8 layout for Flash chip, plus another (uncommitted) SOIC18 layout on the bottom that can mount 2/ea SOIC8s for expansion.
- 2x15 proto area and 3-row headers.

The tiny proto area can mount MOSFETs, voltage-dividers for ADC channels, SIL sensors, even DIP8 opAmps. So, this is another "Do Everything" board that can be customized for specific applications. It can even drive a minimalist robot. So, I just thought some of these features might be incorporated into a Moteino-Gateway pcb, especially the 2x8 uncommitted header and the tiny proto area. An UNO-size board with mega1284 SMT cpu would have lots of free space.

It occurred to me that, for cost-savings reasons, much of this area could be left vacant and people could solder in their own customizations. Moteino is a hardware-hacker world, after all :-).
« Last Edit: January 10, 2016, 03:10:05 PM by oric_dan »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #25 on: January 10, 2016, 04:43:30 PM »
Some of the problems that arise with at least some of the pre-made ESP8266 boards (such as the one you mentioned, and also the adafruit one which I also tried but you didn't mention) is that they include extra parts which get in the way of using them for the purpose of reprogramming an attached Moteino gateway, as generally they don't seem to be built with that as one of their design objectives.  There's a particular capacitor and, IIRC also resistive, value that has to be inline with the DST line of an attached Moteino/arduino or else you can't properly trigger the serial bootloader.  If the ability to do that is not part of your objective, then they would probably work just fine as a conduit for regular serial communications and ordinary OTA wireless Moteino programming.

So, although I would have preferred to use a pre-made board, or at least leverage one, in the end I found it less frustrating to just make my own plain vanilla board where everything about it was known, without extra interfering parts.  Once I did that, everything seemed to "just work".  Possibly/probably someone with more HW savvy than me (and I'm guessing you're one of them) could adapt a pre-made board to do their bidding, so I wouldn't go so far as to say it can't be done.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #26 on: January 10, 2016, 09:32:09 PM »
OK, checking my notes, the schematic for the plain vanilla ESP8266 board is:  http://jeelabs.org/wp-content/uploads/2015/06/Screen-2015-06-12-641.png

To clarify my earlier comments, here's the history of it.  To establish a beginning baseline, I decided to build a "barebones" breadboard arduino on which to do the first wireless programming test.  The reason for that was, again, to have all the components fully known.   So, given that partitioning, that meant a 10K pull-up resister connected between the atmega328p's Vcc and RST pins and a 0.1uf capacitor between the RST pin and the DTR pin in the above schematic.  That worked.

The pullup and capacitor are already correctly in place on the Moteino, so I just connected DTR to DTR, GND to GND, Tx to Rx, Rx to Tx, and V5V to Vin.  Done.

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #27 on: January 10, 2016, 10:09:47 PM »
Quote
(and I'm guessing you're one of them)

Thanks, I'll check out some of the things that have been mentioned. However, I've never actually gotten around to trying reprogramming over RF, so it'll take some learning curve. I was hoping someone already using ESP8266 would [volunteer to] check it for interference with the RFM radio on the same board.

BTW, for anyone wanting to try their own pcb layout, these guys are making boards really inexpensive to prototype anymore [exclusive of some of the off-shore CN sites].
http://pcb4u.com/a1ad77.asp

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #28 on: January 10, 2016, 11:07:29 PM »
I was hoping someone already using ESP8266 would [volunteer to] check it for interference with the RFM radio on the same board.

Quote
If anyone has some test code they'd like me to run

You could just take Felix' gateway sample sketch and monitor the RSSI values it reports on the serial. Then switch on the 8266 with wifi traffic and see if anything changes.

If I'm reading the Gateway sketch (aka "Sample RFM69 receiver/gateway sketch") correctly, it looks as though it only reports RSSI (basically radio.rssi) after a valid packet is received and printed.  So, quick question so I don't have to go digging for answers: isn't radio.rssi the receive strength taken at some instant during the last valid packet's reception?  If so, are you sure that's the figure you're interested in?  I would have thought you'd be interested in the ambient noise level, and wouldn't that be better measured between packets, rather than during packet reception?  Like I said at the beginning, I'm not volunteering to write the measurement code, even if it would be easy to do, but it looks like to move forward with the testing that you all are interested in I'm afraid I'd already be sliding down that slippery slope.
« Last Edit: January 11, 2016, 12:39:19 AM by WhiteHare »

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #29 on: January 11, 2016, 12:40:35 AM »
Myself, I'm not all that familiar with the ins and outs of the radio. I just use modifications of Felix's Node and Gateway sketches. What I would probably try are range checks using low Tx power levels, and then see if signal reliability is impacted when the ESP8266 is fired up next to the RFM radios.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #30 on: January 11, 2016, 01:09:40 AM »
Quote
If I'm reading the Gateway sketch (aka "Sample RFM69 receiver/gateway sketch") correctly, it looks as though it only reports RSSI (basically radio.rssi) after a valid packet is received and printed.

Yeah - but that's exactly how the pi interference shows up. For maybe around half all received packets the RSSI is 15-20 lower than what I'd measure with the gw sketch on a Moteino connected to my MacBook.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #31 on: January 11, 2016, 02:47:57 AM »
Quote
If I'm reading the Gateway sketch (aka "Sample RFM69 receiver/gateway sketch") correctly, it looks as though it only reports RSSI (basically radio.rssi) after a valid packet is received and printed.

Yeah - but that's exactly how the pi interference shows up. For maybe around half all received packets the RSSI is 15-20 lower than what I'd measure with the gw sketch on a Moteino connected to my MacBook.

I believe you, but on its face wouldn't you agree that seems rather bizarre?  According to the Semtech SX1231H datasheet, "The RSSI block evaluates the amount of energy available within the receiver channel bandwidth."  What's bizarre is how could the Pi emit extra RF that would effectively lower the RSSI by that amount?  RSSI is measured during the preamble, so unless the Pi emitted a cancellation wave while RSSI was being measured, it's hard to see how the measured energy would be *less*.  Don't the odds of that seem rather remote?  And if that were happening, wouldn't you also expect to sometimes see the RSSI to be 15-20 higher when the phase of the emissions happen to be additive rather than subtractive?  Yet, it sounds like you're not observing that.

Unless you have a better theory, I'm guessing that's not it but rather the Pi is messing up the RFM69's RSSI calibration.  According to the datasheet, "The receiver is capable of automatic gain calibration, in order to improve the precision of its RSSI measurements.  This function injects a known RF signal at the LNA input, and calibrates the receiver gain accordingly. This calibration is automatically performed during the PLL start-up, making it a transparent process to the end-user."  If the "known R signal" used in the calibration is very low power (?), then the emissions could be low in absolute terms but still high relative to the "known RF signal."

The HopeRF modules do not have a metal lid on them, but some of the other SX1231H module vendors do.  Perhaps part of the reason why they have the lids is to avoid this type of faulty calibration.  If such is the case, I wonder whether retrofitting some kind of DIY metal lid or enclosure onto your RFM69 would solve the problem?  Is there anything quick and dirty you could try to see if that might be so?  e.g. wrap your moteino in aluminum foil with the antenna wire and other outside connector wires poking through?  [Obviously you'd want to take pre-emptive steps to ensure that the aluminum foil doesn't short out the Moteino if you were to try that!]

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #32 on: January 11, 2016, 05:18:49 AM »
I originally did many of the tests you describe. See thread https://lowpowerlab.com/forum/index.php/topic,1008.msg6487.html#msg6487.

And in particular https://lowpowerlab.com/forum/index.php/topic,1008.msg6492.html#msg6492

Aluminum foil did not help at all and it seemed that the source of the problem were the rx/tx lines, not the proximity of the Pi. Things got much better when I switched to a Pi2 so that this no longer caused practical rx issues. But I still see the two "modes".

I agree it's strange. And yeah, maybe the radio reduces its gain because of noise received on the rx/tx lines.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #33 on: January 11, 2016, 12:35:20 PM »
OK.  How many samples should I collect?

BTW, it sure reads like you isolated the cause.  Wouldn't a low-pass filter on the wires connecting the Pi to the RFM69 fix that?

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: what I would like to see ....
« Reply #34 on: January 11, 2016, 01:17:02 PM »
Quote
OK.  How many samples should I collect?

Doesn't need to be a whole lot. Just take 50 values or so and see if it's similar to what you're seeing on your gateway and if the RSSI numbers are consistent. There should be no huge changes whether the 8266 is on or off and over time.

Quote
Wouldn't a low-pass filter on the wires connecting the Pi to the RFM69 fix that?

That could be. I'm running 1Mbit in the serial. Anyone have suggestions what to try component wise to filter out RF noise from RX/TX.

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #35 on: January 11, 2016, 01:44:08 PM »
All in all, I'm a bit surprised it's the RX,Tx lines causing the problem, and not the 700-1000MHz oscillator signals getting into the receiver front-end. However, a simple 3dB low-pass filter is computed from F3dB = 1 / (2*pi*R*C), and 1Mbps corresponds to a 500KHz signal, so values of 330ohms and 1nF would round off the corners of the bitstream a good deal. So, you might try 100ohms and 1nF, or 220ohms and 470pF, or 1K and 100pF, etc. If serial becomes iffy [depends on the wire lengths], then use smaller values again.

EDIT: interestingly, a couple of years ago on the Arduino forum, they noticed a problem with the Rx pin on the DIP40 mega1284P chips. It's located adjacent to the OSC pin, and there was apparently cross-talk from Rx into the oscillator that disrupted operation. [note - only about 1/2 the people were actually seeing this problem]. The original fix put forth was to use a low-pass filter in the Rx line, but then they realized the bootloader chip fuse settings were using the low-power oscillator values, and they changed it to use the full-power oscillator settings, and the problem went away.
« Last Edit: January 11, 2016, 01:55:32 PM by oric_dan »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #36 on: January 11, 2016, 07:55:53 PM »
I ran a simple experiment just now.  I put my ESP8266 right up next to the RFM69HW gateway and ran a node from across the room.  The ESP8266 was *not* directly connected by wire to the RFM69HW (though each was powered by its own AC-DC power source, so there may have been that happening over the common AC ground).  These first numbers were with the ESP8266 powered off:

Code: [Select]
#[1][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[2][2] 1   [RX_RSSI:-57] - ACK sent.
#[3][2] 12   [RX_RSSI:-55] - ACK sent.
#[4][2] 123   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[5][2] 123    [RX_RSSI:-56] - ACK sent.
#[6][2] 123 A   [RX_RSSI:-52] - ACK sent.
#[7][2] 123 AB   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[8][2] 123 ABC   [RX_RSSI:-55] - ACK sent.
#[9][2] 123 ABCD   [RX_RSSI:-56] - ACK sent.
#[10][2] 123 ABCDE   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[11][2] 123 ABCDEF   [RX_RSSI:-54] - ACK sent.
#[12][2] 123 ABCDEFG   [RX_RSSI:-57] - ACK sent.
#[13][2] 123 ABCDEFGH   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[14][2] 123 ABCDEFGHI   [RX_RSSI:-56] - ACK sent.
#[15][2] 123 ABCDEFGHIJ   [RX_RSSI:-58] - ACK sent.
#[16][2] 123 ABCDEFGHIJK   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[17][2] 123 ABCDEFGHIJKL   [RX_RSSI:-55] - ACK sent.
#[18][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-53] - ACK sent.
#[19][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[20][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-55] - ACK sent.
#[21][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-54] - ACK sent.
#[22][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[23][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-56] - ACK sent.
#[24][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-53] - ACK sent.
#[25][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[26][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-54] - ACK sent.
#[27][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-56] - ACK sent.
#[28][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[29][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-53] - ACK sent.
#[30][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-53] - ACK sent.
#[31][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[32][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-54] - ACK sent.
#[33][2] 1   [RX_RSSI:-54] - ACK sent.
#[34][2] 12   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[35][2] 123   [RX_RSSI:-54] - ACK sent.
#[36][2] 123    [RX_RSSI:-55] - ACK sent.
#[37][2] 123 A   [RX_RSSI:-52] - ACK sent. Pinging node 2 - ACK...ok!
#[38][2] 123 AB   [RX_RSSI:-54] - ACK sent.
#[39][2] 123 ABC   [RX_RSSI:-55] - ACK sent.
#[40][2] 123 ABCD   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[41][2] 123 ABCDE   [RX_RSSI:-55] - ACK sent.
#[42][2] 123 ABCDEF   [RX_RSSI:-54] - ACK sent.
#[43][2] 123 ABCDEFG   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[44][2] 123 ABCDEFGH   [RX_RSSI:-56] - ACK sent.
#[45][2] 123 ABCDEFGHI   [RX_RSSI:-56] - ACK sent.
#[46][2] 123 ABCDEFGHIJ   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[47][2] 123 ABCDEFGHIJK   [RX_RSSI:-55] - ACK sent.
#[48][2] 123 ABCDEFGHIJKL   [RX_RSSI:-54] - ACK sent.
#[49][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[50][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-57] - ACK sent.
#[51][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-55] - ACK sent.
#[52][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[53][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-57] - ACK sent.
#[54][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-56] - ACK sent.
#[55][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[56][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-58] - ACK sent.
#[57][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-54] - ACK sent.
#[58][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[59][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-55] - ACK sent.
#[60][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-55] - ACK sent.
#[61][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[62][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-57] - ACK sent.
#[63][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-53] - ACK sent.
#[64][2] 1   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[65][2] 12   [RX_RSSI:-54] - ACK sent.
#[66][2] 123   [RX_RSSI:-56] - ACK sent.
#[67][2] 123    [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[68][2] 123 A   [RX_RSSI:-53] - ACK sent.
#[69][2] 123 AB   [RX_RSSI:-54] - ACK sent.
#[70][2] 123 ABC   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[71][2] 123 ABCD   [RX_RSSI:-57] - ACK sent.
#[72][2] 123 ABCDE   [RX_RSSI:-55] - ACK sent.
#[73][2] 123 ABCDEF   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[74][2] 123 ABCDEFG   [RX_RSSI:-55] - ACK sent.
#[75][2] 123 ABCDEFGH   [RX_RSSI:-55] - ACK sent.
#[76][2] 123 ABCDEFGHI   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[77][2] 123 ABCDEFGHIJ   [RX_RSSI:-55] - ACK sent.
#[78][2] 123 ABCDEFGHIJK   [RX_RSSI:-54] - ACK sent.
#[79][2] 123 ABCDEFGHIJKL   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[80][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-54] - ACK sent.
#[81][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-57] - ACK sent.
#[82][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[83][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-54] - ACK sent.
#[84][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-58] - ACK sent.
#[85][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[86][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-55] - ACK sent.
#[87][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-56] - ACK sent.
#[88][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[89][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-55] - ACK sent.
#[90][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-57] - ACK sent.
#[91][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[92][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-54] - ACK sent.
#[93][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-55] - ACK sent.
#[94][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[95][2] 1   [RX_RSSI:-54] - ACK sent.
#[96][2] 12   [RX_RSSI:-54] - ACK sent.
#[97][2] 123   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[98][2] 123    [RX_RSSI:-54] - ACK sent.
#[99][2] 123 A   [RX_RSSI:-53] - ACK sent.
#[100][2] 123 AB   [RX_RSSI:-52] - ACK sent. Pinging node 2 - ACK...ok!
#[101][2] 123 ABC   [RX_RSSI:-55] - ACK sent.
#[102][2] 123 ABCD   [RX_RSSI:-56] - ACK sent.
#[103][2] 123 ABCDE   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[104][2] 123 ABCDEF   [RX_RSSI:-54] - ACK sent.
#[105][2] 123 ABCDEFG   [RX_RSSI:-55] - ACK sent.
#[106][2] 123 ABCDEFGH   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[107][2] 123 ABCDEFGHI   [RX_RSSI:-58] - ACK sent.
#[108][2] 123 ABCDEFGHIJ   [RX_RSSI:-57] - ACK sent.
#[109][2] 123 ABCDEFGHIJK   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[110][2] 123 ABCDEFGHIJKL   [RX_RSSI:-54] - ACK sent.
#[111][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-53] - ACK sent.
#[112][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[113][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-57] - ACK sent.
#[114][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-55] - ACK sent.
#[115][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[116][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-59] - ACK sent.
#[117][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-60] - ACK sent.
#[118][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-60] - ACK sent. Pinging node 2 - ACK...ok!
#[119][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-58] - ACK sent.
#[120][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-60] - ACK sent.
#[121][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!

[Because of posting character limits, I need to post the next dataset in a follow-on post below].

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #37 on: January 11, 2016, 08:00:50 PM »
These next numbers were with the ESP8266 powered on and connected to the local wi-fi router:
Code: [Select]
#[1][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[2][2] 1   [RX_RSSI:-65] - ACK sent.
#[3][2] 12   [RX_RSSI:-66] - ACK sent.
#[4][2] 123   [RX_RSSI:-67] - ACK sent. Pinging node 2 - ACK...ok!
#[5][2] 123    [RX_RSSI:-66] - ACK sent.
#[6][2] 123 A   [RX_RSSI:-63] - ACK sent.
#[7][2] 123 AB   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[8][2] 123 ABC   [RX_RSSI:-66] - ACK sent.
#[9][2] 123 ABCD   [RX_RSSI:-68] - ACK sent.
#[10][2] 123 ABCDE   [RX_RSSI:-65] - ACK sent. Pinging node 2 - ACK...ok!
#[11][2] 123 ABCDEF   [RX_RSSI:-66] - ACK sent.
#[12][2] 123 ABCDEFG   [RX_RSSI:-66] - ACK sent.
#[13][2] 123 ABCDEFGH   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[14][2] 123 ABCDEFGHI   [RX_RSSI:-65] - ACK sent.
#[15][2] 123 ABCDEFGHIJ   [RX_RSSI:-66] - ACK sent.
#[16][2] 123 ABCDEFGHIJK   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[17][2] 123 ABCDEFGHIJKL   [RX_RSSI:-65] - ACK sent.
#[18][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-63] - ACK sent.
#[19][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[20][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-66] - ACK sent.
#[21][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-65] - ACK sent.
#[22][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[23][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-67] - ACK sent.
#[24][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-65] - ACK sent.
#[25][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-67] - ACK sent. Pinging node 2 - ACK...ok!
#[26][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-64] - ACK sent.
#[27][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-65] - ACK sent.
#[28][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[29][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-65] - ACK sent.
#[30][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-66] - ACK sent.
#[31][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[32][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-64] - ACK sent.
#[33][2] 1   [RX_RSSI:-66] - ACK sent.
#[34][2] 12   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[35][2] 123   [RX_RSSI:-65] - ACK sent.
#[36][2] 123    [RX_RSSI:-67] - ACK sent.
#[37][2] 123 A   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[38][2] 123 AB   [RX_RSSI:-65] - ACK sent.
#[39][2] 123 ABC   [RX_RSSI:-65] - ACK sent.
#[40][2] 123 ABCD   [RX_RSSI:-67] - ACK sent. Pinging node 2 - ACK...ok!
#[41][2] 123 ABCDE   [RX_RSSI:-65] - ACK sent.
#[42][2] 123 ABCDEF   [RX_RSSI:-66] - ACK sent.
#[43][2] 123 ABCDEFG   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[44][2] 123 ABCDEFGH   [RX_RSSI:-65] - ACK sent.
#[45][2] 123 ABCDEFGHI   [RX_RSSI:-65] - ACK sent.
#[46][2] 123 ABCDEFGHIJ   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[47][2] 123 ABCDEFGHIJK   [RX_RSSI:-65] - ACK sent.
#[48][2] 123 ABCDEFGHIJKL   [RX_RSSI:-64] - ACK sent.
#[49][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[50][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-68] - ACK sent.
#[51][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-67] - ACK sent.
#[52][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-65] - ACK sent. Pinging node 2 - ACK...ok!
#[53][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-67] - ACK sent.
#[54][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-66] - ACK sent.
#[55][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-65] - ACK sent. Pinging node 2 - ACK...ok!
#[56][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-66] - ACK sent.
#[57][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-66] - ACK sent.
#[58][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[59][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-65] - ACK sent.
#[60][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-67] - ACK sent.
#[61][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-66] - ACK sent. Pinging node 2 - ACK...ok!
#[62][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-68] - ACK sent.
#[63][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-65] - ACK sent.
#[64][2] 1   [RX_RSSI:-64] - ACK sent. Pinging node 2 - ACK...ok!
#[65][2] 12   [RX_RSSI:-62] - ACK sent.
#[66][2] 123   [RX_RSSI:-64] - ACK sent.
#[67][2] 123    [RX_RSSI:-61] - ACK sent. Pinging node 2 - ACK...ok!
#[68][2] 123 A   [RX_RSSI:-57] - ACK sent.
#[69][2] 123 AB   [RX_RSSI:-57] - ACK sent.
#[70][2] 123 ABC   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[71][2] 123 ABCD   [RX_RSSI:-60] - ACK sent.
#[72][2] 123 ABCDE   [RX_RSSI:-54] - ACK sent.
#[73][2] 123 ABCDEF   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[74][2] 123 ABCDEFG   [RX_RSSI:-55] - ACK sent.
#[75][2] 123 ABCDEFGH   [RX_RSSI:-55] - ACK sent.
#[76][2] 123 ABCDEFGHI   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[77][2] 123 ABCDEFGHIJ   [RX_RSSI:-55] - ACK sent.
#[78][2] 123 ABCDEFGHIJK   [RX_RSSI:-55] - ACK sent.
#[79][2] 123 ABCDEFGHIJKL   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[80][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-53] - ACK sent.
#[81][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-56] - ACK sent.
#[82][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[83][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-56] - ACK sent.
#[84][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-59] - ACK sent.
#[85][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[86][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-57] - ACK sent.
#[87][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-59] - ACK sent.
#[88][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[89][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-57] - ACK sent.
#[90][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-59] - ACK sent.
#[91][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[92][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-57] - ACK sent.
#[93][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-60] - ACK sent.
#[94][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[95][2] 1   [RX_RSSI:-56] - ACK sent.
#[96][2] 12   [RX_RSSI:-56] - ACK sent.
#[97][2] 123   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[98][2] 123    [RX_RSSI:-56] - ACK sent.
#[99][2] 123 A   [RX_RSSI:-52] - ACK sent.
#[100][2] 123 AB   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[101][2] 123 ABC   [RX_RSSI:-54] - ACK sent.
#[102][2] 123 ABCD   [RX_RSSI:-55] - ACK sent.
#[103][2] 123 ABCDE   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[104][2] 123 ABCDEF   [RX_RSSI:-60] - ACK sent.
#[105][2] 123 ABCDEFG   [RX_RSSI:-60] - ACK sent.
#[106][2] 123 ABCDEFGH   [RX_RSSI:-63] - ACK sent. Pinging node 2 - ACK...ok!
#[107][2] 123 ABCDEFGHI   [RX_RSSI:-62] - ACK sent.
#[108][2] 123 ABCDEFGHIJ   [RX_RSSI:-62] - ACK sent.

Just eye-balling the numbers, there does seem to be some noticeable skewing between the control (OFF) and the experiment (ON).  FWIW, the RFM69HW gateway is set at 915Mhz.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #38 on: January 11, 2016, 08:32:05 PM »
OK, I just now ran the ESP8266 off a battery, with the same arrangement, and so now there is no direct physical connection between the ESP8266 and the RFM69HW.  The skewing looks mitigated:

Code: [Select]
#[1][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[2][2] 1   [RX_RSSI:-58] - ACK sent.
#[3][2] 1   [RX_RSSI:-59] - ACK sent.
#[4][2] 12   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[5][2] 123   [RX_RSSI:-62] - ACK sent.
#[6][2] 123    [RX_RSSI:-60] - ACK sent.
#[7][2] 123 A   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[8][2] 123 AB   [RX_RSSI:-54] - ACK sent.
#[9][2] 123 ABC   [RX_RSSI:-56] - ACK sent.
#[10][2] 123 ABCD   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[11][2] 123 ABCDE   [RX_RSSI:-53] - ACK sent.
#[12][2] 123 ABCDEF   [RX_RSSI:-53] - ACK sent.
#[13][2] 123 ABCDEFG   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[14][2] 123 ABCDEFGH   [RX_RSSI:-55] - ACK sent.
#[15][2] 123 ABCDEFGHI   [RX_RSSI:-58] - ACK sent.
#[16][2] 123 ABCDEFGHIJ   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[17][2] 123 ABCDEFGHIJK   [RX_RSSI:-58] - ACK sent.
#[18][2] 123 ABCDEFGHIJKL   [RX_RSSI:-57] - ACK sent.
#[19][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[20][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-59] - ACK sent.
#[21][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-59] - ACK sent.
#[22][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[23][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-58] - ACK sent.
#[24][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-59] - ACK sent.
#[25][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[26][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-59] - ACK sent.
#[27][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-59] - ACK sent.
#[28][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[29][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-59] - ACK sent.
#[30][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-58] - ACK sent.
#[31][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[32][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-57] - ACK sent.
#[33][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-59] - ACK sent.
#[34][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[35][2] 1   [RX_RSSI:-55] - ACK sent.
#[36][2] 12   [RX_RSSI:-56] - ACK sent.
#[37][2] 123   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[38][2] 123    [RX_RSSI:-58] - ACK sent.
#[39][2] 123 A   [RX_RSSI:-56] - ACK sent.
#[40][2] 123 AB   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[41][2] 123 ABC   [RX_RSSI:-58] - ACK sent.
#[42][2] 123 ABCD   [RX_RSSI:-58] - ACK sent.
#[43][2] 123 ABCDE   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[44][2] 123 ABCDEF   [RX_RSSI:-58] - ACK sent.
#[45][2] 123 ABCDEFG   [RX_RSSI:-56] - ACK sent.
#[46][2] 123 ABCDEFGH   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[47][2] 123 ABCDEFGHI   [RX_RSSI:-58] - ACK sent.
#[48][2] 123 ABCDEFGHIJ   [RX_RSSI:-59] - ACK sent.
#[49][2] 123 ABCDEFGHIJK   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[50][2] 123 ABCDEFGHIJKL   [RX_RSSI:-58] - ACK sent.
#[51][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-56] - ACK sent.
#[52][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[53][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-59] - ACK sent.
#[54][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-55] - ACK sent.
#[55][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[56][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-60] - ACK sent.
#[57][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-58] - ACK sent.
#[58][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-60] - ACK sent. Pinging node 2 - ACK...ok!
#[59][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-55] - ACK sent.
#[60][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-59] - ACK sent.
#[61][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[62][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-58] - ACK sent.
#[63][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-56] - ACK sent.
#[64][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[65][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-56] - ACK sent.
#[66][2] 1   [RX_RSSI:-55] - ACK sent.
#[67][2] 12   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[68][2] 123   [RX_RSSI:-55] - ACK sent.
#[69][2] 123    [RX_RSSI:-56] - ACK sent.
#[70][2] 123 A   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[71][2] 123 AB   [RX_RSSI:-56] - ACK sent.
#[72][2] 123 ABC   [RX_RSSI:-56] - ACK sent.
#[73][2] 123 ABCD   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[74][2] 123 ABCDE   [RX_RSSI:-56] - ACK sent.
#[75][2] 123 ABCDEF   [RX_RSSI:-55] - ACK sent.
#[76][2] 123 ABCDEFG   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[77][2] 123 ABCDEFGH   [RX_RSSI:-57] - ACK sent.
#[78][2] 123 ABCDEFGHI   [RX_RSSI:-58] - ACK sent.
#[79][2] 123 ABCDEFGHIJ   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[80][2] 123 ABCDEFGHIJK   [RX_RSSI:-57] - ACK sent.
#[81][2] 123 ABCDEFGHIJKL   [RX_RSSI:-55] - ACK sent.
#[82][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[83][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-59] - ACK sent.
#[84][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-58] - ACK sent.
#[85][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[86][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-58] - ACK sent.
#[87][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-58] - ACK sent.
#[88][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[89][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-58] - ACK sent.
#[90][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-55] - ACK sent.
#[91][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[92][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-56] - ACK sent.
#[93][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-57] - ACK sent.
#[94][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[95][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-56] - ACK sent.
#[96][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-54] - ACK sent.
#[97][2] 1   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[98][2] 12   [RX_RSSI:-54] - ACK sent.
#[99][2] 123   [RX_RSSI:-55] - ACK sent.
#[100][2] 123    [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[101][2] 123 A   [RX_RSSI:-54] - ACK sent.
#[102][2] 123 AB   [RX_RSSI:-55] - ACK sent.
#[103][2] 123 ABC   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[104][2] 123 ABCD   [RX_RSSI:-57] - ACK sent.
#[105][2] 123 ABCDE   [RX_RSSI:-55] - ACK sent.
#[106][2] 123 ABCDEF   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[107][2] 123 ABCDEFG   [RX_RSSI:-56] - ACK sent.
#[108][2] 123 ABCDEFGH   [RX_RSSI:-56] - ACK sent.
#[109][2] 123 ABCDEFGHI   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[110][2] 123 ABCDEFGHIJ   [RX_RSSI:-57] - ACK sent.
#[111][2] 123 ABCDEFGHIJK   [RX_RSSI:-58] - ACK sent.
#[112][2] 123 ABCDEFGHIJKL   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[113][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-57] - ACK sent.
#[114][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-57] - ACK sent.
#[115][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[116][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-55] - ACK sent.
#[117][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-56] - ACK sent.
#[118][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[119][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-55] - ACK sent.
#[120][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-56] - ACK sent.
#[121][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[122][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-56] - ACK sent.
#[123][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-58] - ACK sent.
#[124][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[125][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-56] - ACK sent.
#[126][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-59] - ACK sent.
#[127][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[128][2] 1   [RX_RSSI:-57] - ACK sent.

« Last Edit: January 11, 2016, 08:34:52 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #39 on: January 11, 2016, 08:44:13 PM »
Earlier, I ran a dataset with no ESP8266 nearby the RFM69HW, and here's how that looked:

Code: [Select]
#[1][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[2][2] 1   [RX_RSSI:-58] - ACK sent.
#[3][2] 12   [RX_RSSI:-58] - ACK sent.
#[4][2] 123   [RX_RSSI:-60] - ACK sent. Pinging node 2 - ACK...ok!
#[5][2] 123    [RX_RSSI:-60] - ACK sent.
#[6][2] 123 A   [RX_RSSI:-57] - ACK sent.
#[7][2] 123 AB   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[8][2] 123 ABC   [RX_RSSI:-58] - ACK sent.
#[9][2] 123 ABCD   [RX_RSSI:-61] - ACK sent.
#[10][2] 123 ABCDE   [RX_RSSI:-58] - ACK sent. Pinging node 2 - ACK...ok!
#[11][2] 123 ABCDEF   [RX_RSSI:-56] - ACK sent.
#[12][2] 123 ABCDEFG   [RX_RSSI:-54] - ACK sent.
#[13][2] 123 ABCDEFGH   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[14][2] 123 ABCDEFGHI   [RX_RSSI:-59] - ACK sent.
#[15][2] 123 ABCDEFGHIJ   [RX_RSSI:-59] - ACK sent.
#[16][2] 123 ABCDEFGHIJK   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[17][2] 123 ABCDEFGHIJKL   [RX_RSSI:-53] - ACK sent.
#[18][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-54] - ACK sent.
#[19][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[20][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-55] - ACK sent.
#[21][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-52] - ACK sent.
#[22][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[23][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-53] - ACK sent.
#[24][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-53] - ACK sent.
#[25][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-52] - ACK sent. Pinging node 2 - ACK...ok!
#[26][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-52] - ACK sent.
#[27][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-55] - ACK sent.
#[28][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[29][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-56] - ACK sent.
#[30][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-56] - ACK sent.
#[31][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[32][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-54] - ACK sent.
#[33][2] 1   [RX_RSSI:-54] - ACK sent.
#[34][2] 12   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[35][2] 123   [RX_RSSI:-54] - ACK sent.
#[36][2] 123    [RX_RSSI:-54] - ACK sent.
#[37][2] 123 A   [RX_RSSI:-52] - ACK sent. Pinging node 2 - ACK...ok!
#[38][2] 123 AB   [RX_RSSI:-54] - ACK sent.
#[39][2] 123 ABC   [RX_RSSI:-54] - ACK sent.
#[40][2] 123 ABCD   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[41][2] 123 ABCDE   [RX_RSSI:-55] - ACK sent.
#[42][2] 123 ABCDEF   [RX_RSSI:-54] - ACK sent.
#[43][2] 123 ABCDEFG   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[44][2] 123 ABCDEFGH   [RX_RSSI:-54] - ACK sent.
#[45][2] 123 ABCDEFGHI   [RX_RSSI:-55] - ACK sent.
#[46][2] 123 ABCDEFGHIJ   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[47][2] 123 ABCDEFGHIJK   [RX_RSSI:-54] - ACK sent.
#[48][2] 123 ABCDEFGHIJKL   [RX_RSSI:-55] - ACK sent.
#[49][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[50][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-59] - ACK sent.
#[51][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-55] - ACK sent.
#[52][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[53][2] 123 ABCDEFGHIJKLMNOPQ   [RX_RSSI:-56] - ACK sent.
#[54][2] 123 ABCDEFGHIJKLMNOPQR   [RX_RSSI:-56] - ACK sent.
#[55][2] 123 ABCDEFGHIJKLMNOPQRS   [RX_RSSI:-53] - ACK sent. Pinging node 2 - ACK...ok!
#[56][2] 123 ABCDEFGHIJKLMNOPQRST   [RX_RSSI:-55] - ACK sent.
#[57][2] 123 ABCDEFGHIJKLMNOPQRSTU   [RX_RSSI:-55] - ACK sent.
#[58][2] 123 ABCDEFGHIJKLMNOPQRSTUV   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[59][2] 123 ABCDEFGHIJKLMNOPQRSTUVW   [RX_RSSI:-53] - ACK sent.
#[60][2] 123 ABCDEFGHIJKLMNOPQRSTUVWX   [RX_RSSI:-56] - ACK sent.
#[61][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXY   [RX_RSSI:-56] - ACK sent. Pinging node 2 - ACK...ok!
#[62][2] 123 ABCDEFGHIJKLMNOPQRSTUVWXYZ   [RX_RSSI:-56] - ACK sent.
#[63][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-55] - ACK sent.
#[64][2] 1   [RX_RSSI:-55] - ACK sent. Pinging node 2 - ACK...ok!
#[65][2] 12   [RX_RSSI:-54] - ACK sent.
#[66][2] 123   [RX_RSSI:-54] - ACK sent.
#[67][2] 123    [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[68][2] 123 A   [RX_RSSI:-50] - ACK sent.
#[69][2] 123 AB   [RX_RSSI:-51] - ACK sent.
#[70][2] 123 ABC   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[71][2] 123 ABCD   [RX_RSSI:-54] - ACK sent.
#[72][2] 123 ABCDE   [RX_RSSI:-53] - ACK sent.
#[73][2] 123 ABCDEF   [RX_RSSI:-52] - ACK sent. Pinging node 2 - ACK...ok!
#[74][2] 123 ABCDEFG   [RX_RSSI:-52] - ACK sent.
#[75][2] 123 ABCDEFGH   [RX_RSSI:-54] - ACK sent.
#[76][2] 123 ABCDEFGHI   [RX_RSSI:-54] - ACK sent. Pinging node 2 - ACK...ok!
#[77][2] 123 ABCDEFGHIJ   [RX_RSSI:-56] - ACK sent.
#[78][2] 123 ABCDEFGHIJK   [RX_RSSI:-58] - ACK sent.
#[79][2] 123 ABCDEFGHIJKL   [RX_RSSI:-57] - ACK sent. Pinging node 2 - ACK...ok!
#[80][2] 123 ABCDEFGHIJKLM   [RX_RSSI:-57] - ACK sent.
#[81][2] 123 ABCDEFGHIJKLMN   [RX_RSSI:-62] - ACK sent.
#[82][2] 123 ABCDEFGHIJKLMNO   [RX_RSSI:-59] - ACK sent. Pinging node 2 - ACK...ok!
#[83][2] 123 ABCDEFGHIJKLMNOP   [RX_RSSI:-59] - ACK sent.

BTW, the node and the gateway were stationary and unmoved throughout all this. 

Unfortunately, because of family obligations I now need to pack things up, but on its face it looks to me like there's a pattern there over common AC ground similar in character to what Joe observed with his direct wired connection.  I haven't yet run a dataset  with the ESP8266 directly connected to the RFM69HW.  That will have to wait for another time, but based on the above I'd expect to see skewing.

Was the above helpful?  I took some photos if you're curious to see how the setup looked.  As for me, I would not have expected these results, so from my point of view it was a worthwhile experiment.  My initial thought is that the RFM69HW is very sensitive to ground noise.
« Last Edit: January 11, 2016, 09:08:43 PM by WhiteHare »

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #40 on: January 11, 2016, 09:27:24 PM »
Yeah, those results look significant. If you get a chance to run some more, for comparison purposes, you might try using setPowerLevel(n) with n=0 or other low-values to see how it looks for low Tx power levels. And with the Moteino nodes a good ways apart, 30 feet at least.

To me, the ideal test would have the RFM radio and ESP8266 about 4" apart and run off the same power buss on the same Moteino board.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #41 on: January 12, 2016, 10:00:51 AM »
Doesn't yesterday's experiment highlight the problem as most likely common mode noise?  If so, then I'm under the impression that a low pass filter, like the above, aimed at normal mode noise isn't going to be sufficient.  I'm at square 1 on this, but I'm guessing some sort of choke circuit is going to be needed, regardless of whether the RFM69HW is connected to a Pi or an ESP8266:  http://www.radio-electronics.com/articles/circuit-design/resolving-emi-common-mode-normal-146.   Can anyone recommend a generic choke circuit that could be adapted to work?  If there were a generic model to leverage, then perhaps if there were few enough parameters to juggle, a few "monte carlo" type experiments might expose a good enough answer while sidestepping the theory needed for an optimal answer.  Even better would be doing the monte carlo on a simulation, which probably exists somewhere.  On the other hand, if anyone reading this knows how to compute an optimal circuit wrt common mode noise, that would of course be preferable!

The alternative is to look for a radio module that already has adequate noise suppression built into it, and maybe those exist given how sensitive the SX1231H appears to be.
« Last Edit: January 12, 2016, 10:23:13 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #42 on: January 12, 2016, 10:59:20 AM »
Maybe this won't be too difficult.  As a starting point, it looks like I might simply pick a common-mode filter (CMF) that's optimized for the OTA frequency used by the RFM69HW, which in my case would be about 915Mhz:  https://product.tdk.com/en/products/emc/guidebook/eemc_product_05.pdf  Would that work?  Or would I need to mitigate at other frequencies also?
« Last Edit: January 12, 2016, 11:05:41 AM by WhiteHare »

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #43 on: January 12, 2016, 12:18:10 PM »
Quote
Doesn't yesterday's experiment highlight the problem as most likely common mode noise?

I believe you're right on that. RF design is not my area, so I'm not really the guy for this. It's all magic to me. One problem is, you don't know what you really have until you get a board totally designed and tested. Hooking anything up via jumpers, and having wires going to the power mains are probably going to produce large inductive loops that radiate, so a nice final layout gets away from most of that stuff.

If someone does want to put 2 radios on the same pcb, like the putative Moteino-Gateway, then it likely would be best to use your common-mode filters on the board. But there still may be a problem with direct radiation between radios. Short of putting in common-mode chokes like you mentioned, it might also with just the differential-mode arrangement shown here in figure 14, but probably not as effectively. But now things are starting to get rather complex, and away from being a nice cheap Moteino-Gateway board too.
http://www.eetimes.com/document.asp?doc_id=1272503

This is all a bag of worms to me, I build robots :-). Oh well, the idea of RFM radio and ESP8266 both on a single board was mainly a passing-thought in any case.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #44 on: January 12, 2016, 01:42:47 PM »
Well, conversely, one can  take the view that if you have adequate link budget, the reduced RSSI doesn't really matter, and so resolving it, while desirable, is little more than icing on the cake.  For instance, I wasn't even aware of the issue until I specifically went looking for it.  Besdes, it's probably not even reduced RSSI, just an "apparent" reduced RSSI because of mis-calibration.  Actual SNR might be largely unaffected.  So, in the end, I'm not sure that it even matters provided that the RSSI threshold is crossed enough for the radio to initiate packet capture, and so perhaps lowering the threshold by an equal amount would compensate.

Anyhow, this is more than I care to take on alone.  If those who are using the Pi with Moteino don't care enough to want to resolve it, then I guess neither do I.
« Last Edit: January 12, 2016, 01:45:29 PM by WhiteHare »

oric_dan

  • Jr. Member
  • **
  • Posts: 64
Re: what I would like to see ....
« Reply #45 on: January 12, 2016, 02:46:49 PM »
Quote
if you have adequate link budget, the reduced RSSI doesn't really matter, and so resolving it, while desirable, is little more than icing on the cake.
Yeah, my experience with the RFM69 radio is that I have more than enough RSSI to spare where I use it. You'll notice my post on the other thread, where I was getting RSSI about -80 dBm [still approx 20 dB above rcvr threshold] across 500' distance from inside my car to inside a metal-frame bldg. That's phenomenal to me.
https://lowpowerlab.com/forum/index.php/topic,1494.0.html

Inside the house, I can use even minimal Tx power [~5 dBm] and have good RSSI at 30' distance, so all in all, the problem you've been finding might only be an issue for extreme cases. But I think we have good perspective on this now, something to cite. And like I mentioned previously, if an uncommitted 2x8 header where laidout on a Moteino-Gateway pcb, then people could play all they like with such setups. Probably better that than trying to build it all in from the get-go.

I might actually try it down the road, using both radios on my RF-Node pcb shown earlier, and then report back. Right now, I just got my robot tank RoBurt going 3 days ago [at long last after a lot of work], using Moteino radios for comms from robot to PC, so I'm hot to carry on there. There is currently over 60-pages of code, so my head is spinning already, DUH.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: what I would like to see ....
« Reply #46 on: March 20, 2016, 02:57:07 PM »
Closing the loop, yesterday I soldered the ESP8266 parts to a PCB (the previous version looked like a Dupont wire orgy and also used a different 3.3v voltage regulator), and then ran RSSI measurements using a narrower bandwidth and my now more evolved methods for capturing RSSI noise.

The good news is that with a regular Moteino R4 with a wire antenna, and with the improved ESP8266 just a couple inches from the antenna, there was no meaningful difference in the amount of RSSI noise detected.

For those interested in the details of the comparison, see:
http://pastebin.com/vC5bx0fs
and
http://pastebin.com/g2tqNi3W

[Edit1: the above two measurements were taken with the Moteino R4 and ESP8266 (an ESP13) on separate circuits, each with their own power supplies run from batteries.  The good news is that powering them both from the ESP8266's power supply (an LM1117T-3.3v powered by four AA batteries), yields the same level of RSSI noise as when the R4 and ESP13 were not directly connected:  http://pastebin.com/sCmXAhwg]

[Edit2: OK, I just connected the Rx and Tx of the ESP13 to the Moteino R4, remeasured, and also no meaningful change in RSSI noise: average RSSI noise measured over 1000 samples at this same narrow bandwidth is -118.79.  BTW, since all this is just an experiment, I am using Dupont wires to connect the ESP13 to the R4.  ]
« Last Edit: March 20, 2016, 04:51:08 PM by WhiteHare »