Messages posted by: stevech

Yagi - needs to connect to a radio board that has SMA or U.FL. If neither, you can wire an SMA to the board using 1 inch or so or less of wire for the center conductor, and for ground, take the braid from coax cable and a hot soldering iron and make a fat ground connection between the ground plane near the antenna connector.

Yagi at 900MHz band would need lots of elements to get enough gain to matter. Like 4 ft. or more long.
Mount radio in weatherproof box on mast with antenna to keep coax from antenna to radio very short.

Choose narrowest possible channel width and data rate - these affect range a great deal.

claudebizier wrote:Hello

I look for a new application with wireless sensor. I need one master and some 4-6 slaves, distance about 30 meters indoor. I look HM-TRP module but it's seam to be work one on one !

So, Is somebody had ever make this application. Which module could be the best choice.

the module could pass FCC normes.

thanks for informations

What is being sensed? By what sort of sensor? At what rates?

given the radio is half-duplex, what's the need?

LoRa radios are usually spread spectrum rather than FM/FSK. And LoRa, to get their long range, need low frequency (not 2.4GHz), very low bit (data) rates, small packets.

jeremyvnc wrote:Thanks for the link to the calculator. In my testing with the RFM69HCW modules, I didn't see a difference between the 1/4, 1/2, and full wave antenna lengths. They all seemed to drop off at the same distance and it didn't really hurt or change the close range reliability. I do know that without any antenna, the range is severely limited and easily blocked by a person standing in the LOS.

Differences among those antennas is just 2-6dB or so. Each will differ in impedance matching (VSWR). Best to use 1/4 wave.

Range is more affected by choice of channel width and bit rate than by a few dB of antenna differences. And of course, line of sight-ness.

is the receiving device also sleeping? Or is the receiving end a "hub" that's always-on?

If both sleep, you need good time sync between the two. And RH doesn't do that. It's more complex than you'd imagine.

Hopefully, you system is a star topology with a mains-powered hub.

It's up to your app to set the correct/desired bands and frequency within the band.
The RH libraries have defaults but the library cannot know what band the hardware is designed for... the radios are identical. The external RF components (inductors, capacitors) are band-specific.
The part number you ordered has a part number portion.
Unlikely that Anarduino shipped a PCB with external RF components for a band other than what you ordered.

A test might confirm:
Put to identical boards on bench-top, about 1m apart. Line of sight between them.

Load firmware in both, compiled for 915MHz ( or 868MHz in the EU). Run and note the RSSI reported by each.
Load firmware in both for the other band (e.g., 433MHz). If the RSSI is (on average) over 10dB better, then this is the correct band. If 10dB or so poorer (more negative RSSI), the hardware filters are for the other band.

Note that in the US and other regulatory regions, the transmitter on-time (duty cycle) is very restricted in the 433MHz band. It will have about 4dB of advantage over the 902-928MHz band due to reduced line of sight path loss. But 4Db is a nit in link budget.

Go by what's marked on the board.
The demo software could have been for the other band

Hopez wrote:Thank you for the answer, i use the simplest RFM69 library and it works well, i have tried to use the Radiohead after change the init setting to the anarduino
pin SS and IRQ pin 2, the initialization is ok, but the ping pong from server to client don't work. Is there a problem if the server is on the first floor over the
garden where ther is the client anarduino? And for 815 Mhz i should use a 33 cm antenna o a 16,5 antenna?

I'll assume your 816MHz above is a typo for 915. Don't use that in the EU. I'm not sure about UK and elsewhere.

RadioHead is the way to go. Get a pair of microprocessors w/radios working at a short range (same room). Understand how to use the APIs in RadioHead. Then go for range and unattended radios.
Choose one of the 12 or so GFSK radio configurations, say, 9600 Baud in channel about twice that wide (2x9600Hz).

Antenna.. approximately 1/4 wavelength at your radio's frequency. The RFM69HW's are sold to operate only in one of two bands: 433MHz and 868MHz (EU) + 902-928MHz in No. America. Radio has poor range if tuned to the wrong band.
Antennas for 868MHz and the 915MHz (center) can be the same.

RFM69HW (high power), modest data rate and modest channel width and modulation index, clear line of sight, max TX power, expect perhaps 100-300m in the 868/915MHz ISM bands. The key is to choose the prudent predefined modulation mode from the table built into RadioHead.

a quick glance.. those modules are on-off-keying (OOK) based on carrier on/off. Also called Amplitude Shift Keying, ASK, (digitally, 1 or 0).
These are too cheap. OOKs are a PITA.
What you see on your scope is normal. It's the absence of a received signal. Like an FM walkie talkie with the squelch open.
These OOKs rely on a transmitted signal of carrier on/off/on/off, etc, in Manchester coding so that no long strings of 1's or 0's are sent.
The OOK receiver has a "data slicer". This keeps the average carrier on/off as an integration - a low pass filter. An average of the 1's and 0's.
To detect 1's and 0's, the average in analog form is compared to the instantaneous voltage from the carrier signal, rectified to DC. (over simplifying).

The data slicer outputs the 1's and 0's based on comparing the average to the instant. If the data has too many 1's or 0's in a row, the average goes too high or too low and the data won't demodulate properly.
Often the data slicer is an op-amp.

So you trade off low cost modules for YOU having to find or develop the proper bit-by-bit encoding.

Rather than one of the FM modules. And these have a full packet engine aboard.

Avoid OOK/ASK radios, I say.

OP: Have you looked at RadioHead as your protocol stack? Then choose among it's radio modules supported.
RFM69 perhaps.
Don't try to start with a bare radio and no protocol stack (such as reliable datagrams with ACKs and retransmissions - as in RadioHead).

You cannot run 1Mbps in 433MHz. Illegal and the band is too small to accommodate that channel width.
If in No. America, and some Asian, use 902-928MHz. RFM69HW for that band. Else 868MHz for the EU.
Expecting 100+Kbps net yield (not the raw bit rate) is realistic IF you can get the received signal strength high enough for a large SNR.

If this is a point to point link, you can use yagii or other antennas with 8dBi or more gain in the 915MHz area. Of practical size/cost. Far better to use antenna gain than TX power.

You need to describe the path from A to B radio sites: Distance, clear line of sight? Antenna elevations? Fresnel zone clearance desired. You can calculate the received signal strength, or I'll do it if you tell me the path details.

About all I can add is that all mega328 based Anarduino boards I've seen come pre-programmed with a version of optiboot for the bootloader. Baud rate is usually either 56K or 115.2K.

I've used Tadiran on military projects. Good. But very pricey.
They make super high capacity C and D cells that cannot deliver high current so one bridges them with a superCap for the bursts, and the superCap recharges from the Tadiran exotic-chemistry cells.
Burst - like an MCU wakeup, receive, transmit, sleep cycle of say 50mSec.

some folks use this stack
http://www.airspayce.com/mikem/arduino/RadioHead/

I have

terrestrial RF path - buildings, trees unless from high rooftop to rooftop
vs
airborne platform RF path - line of sight, no obstructions

Yes?

1kM in terrestrial conditions is excellent with simple antennas, low elevation, ISM band

try this download
two programs.
I haven't tried to build using the new Arduino IDE.

Perhaps the .hex is in the debug folder, ready to use.

https://www.adrive.com/public/fR2uMe/RadioHead%20tests

If the AVR code hangs in send (transmit), it's often because the interrupt (IRQ) wire from the radio to the AVR is not wired or the IRQ bit isn't declared correctly in the class constructor. But the software defaults should be OK.

what baud rate is the IDE using? 115200? It may be that some bootloaders are at 57600

those boards' bootloader use a different baud rate?

pretty hard to damage a bootloader without using an ISP wired up to the AVR.

I got it into 1KB with a 50 or so to spare. Boot from UART or SPI Flash.
I did so by coding a lot from scratch and omitting what I considered to be historical clutter.

Don't forget that a .hex file is about 2.2 times the size of the actual binary image, since a hex file is binary coded to ASCII hex per an Intel standard.

Antenna absent - I've done it often when doing desktop testing and range isn't important.

second SPI device wired up to board... here are the considerations
- added SPI device needs its own unique chip select (SS) bit
- The radioHead interrupt service routine will use the SPI port unaware that there may have been a concurrent SPI by the second SPI device

As to the second point, there are two ways I know of to deal with this "mutual exclusion" access to a shared device (that being the SPI controller).
1. When the second device starts to use the SPI port, it must first cause the radio to switch to the idle mode where the receiver and transmitter are "off" and cannot interrupt. The SPI can then be used for the second SPI device without risk of a radio's interrupt trying to also use the SPI port. Downside: If the second device hogs too much time, an message may be missed. If the message uses the RadioHead reliable datagram protcol, the sender will delay and retry and hopefully the second device will have finished its uses of the SPI and reenabled the receiver by calling available().
2. Arduino (latest) libraries have a function "SPI Transactions". With this, a program contends for use of the SPI port. When the transaction is permitted, the other (radio) usage will have its interrupt disabled until the transaction is finished. This transaction concept does NOT work well with real-time, perishable data as is the case for wireless messaging. Transactions work well for non-real-time such as SPI flash memory, LEDs, and so on.

I use approach (1) due to the real-time nature of wireless.

Ideally, one uses an MCU with two SPI ports as are common on the small ARM boards like Teensy 3.x and Teensy LC. This avoids the contention.

that's a polling scheme rather than having the sensors report "by exception", such as

> x amount of time since last report
sensed parameter changed by more than x percent

I suggest using the same radio for all nodes.
Are the remotes to be battery powered? This is a key decision item.

An Anarduino mini-wireless can interface/bridge the wireless network to a PC via the mini-wireless' serial port.
You'll need to write the bridging software and the PC software using the PC's serial port.
Or the serial port on a RPi. And perhaps use Python on the RPi.
I've done the above for use with moving sensors.

I vaguely recall that the two do not interoperate.