Arhhh - no big problem. It will help clean up the conversations!!
If you know a topic name - for example the auto fill of the URLs in your browser will hold the names of those recently browsed. Then you can search on those in Goggle and dial up the cached page of the topic. Best to do it before Goggle overwrites them:
Efficiency of 1V to 5V step-up module.txt
I also had to recreate my log in and my reputation has been trashed as well !!
"Are there any guidelines on how to convert a sketch that was made for the 1.3 libraries to 1.4?
I would very much like to use the DimmableLED sketch but I know too little about coding. I found a few obvious differences but nevertheless did not succeed in making the sketch work.
I found it here: http://forum.micasaverde.com/index.php/topic,23342.0.html and I know the maker blacey is also on this forum and think it is a very nice sketch. The only way I see how to get this to work is to downgrade to the 1.3 libraries but than I would have to start all over."
<>
It's not easy to cover all possibilities but here are a few notes and examples based on a temperature sensor plus some other info that might help with the DimmableSketch. I can re-edit this post if there are any corrections needed or something else needs to be added.
AT THE START OF THE PROGRAM:
#include <Sensor.h> change to #include <MySensor.h>
#include <EEPROM.h> <-- this line is no longer required - delete
#include <RF24.h> <-- this line is no longer required - delete
Sensor gw; change to --> MySensor gw;
Sensor gw(9,10); change to --> MySensor gw;
// Initialize temperature message <-- insert line
MyMessage msg(0,V_TEMP); <-- insert line
IN void setup():
// send the Sketch Version Information to the Gateway <-- insert line
gw.sendSketchInfo("My sketch name", "0.50"); <-- insert line
gw.sendSensorPresentation(i, S_TEMP); change to --> gw.present(i, S_TEMP);
metric = gw.isMetricSystem(); change to --> metric = gw.getConfig().isMetric;
IN void loop():
// process incoming messages (like config from server) <-- insert line
gw.process(); <-- insert line
gw.sendVariable(i, V_TEMP, temperature, 1); change to --> gw.send(msg.setSensor(i).set(temperature,1)); // send float with one decimal point
SEARCH FOR THE FOLLOWING:
gw.powerUp(); <-- this line is no longer required - delete if found
sendSensorPresentation change variable name to --> present
If the following is found then this can be deleted:
// Set RADIO_ID to something unique in your sensor network (1-254)
// or set to AUTO if you want gw to assign a RADIO_ID for you.
#define RADIO_ID AUTO
If the #define RADIO_ID AUTO was found and deleted as above then change this also
gw.begin( RADIO_ID ); change to --> gw.begin();
OTHER EXAMPLE MESSAGES:
// batteryPcnt is a uint8_t
gw.sendBatteryLevel(batteryPcnt);
// I've not checked this
gw.sendVariable( 0, V_DIMMER, currentLevel ); change to --> gw.send(currentLevel);
INITIALIZING THE SENSOR TO HANDLE A MESSAGE FROM THE MAIN GATEWAY:
// handle incoming messages
void incomingMessage(MyMessage message)
{
// handle your messages here
// I've not checked this
setDimmableLEDState(message);
}
// the call back incomingMessage receives any incoming messages
gw.begin(incomingMessage);(Note this is a resurrected post). I will stick my neck out on this one - hope I have the following correct:
The low noise amp gain is 10dB and the power amplifier is 20 dB. If both ends use the PCB with the LNA & PA, then the link is up 30 dB on the standard radios. With line of sight and that also means the antennas must be high enough to be unaffected by the Fresnel Zone; that being 5.6m high for a distance of one km. Then every 6 dB extra doubles the range. So 30dB/6 = 5 So range is extended by 2^5 = 32 times. It's claimed the powered modules can transmit about 1000m, which implies the standard modules have a line of sight range of about 31m.
However, if you have a standard module at one end and a powered module at the other end, you only increase the link gain by the receiver gain of 10 dB, which just gives 3 times [ = 10^(10dB/20)] the distance of a standard radio, not 32 times [ = 10^(30dB/20)]. So the 31m above get's extended to just about 90m.
It changes for indoors. An approximation is used, whereby 12 dB increase in power is said to be required to double the distance (where only 6dB is required for line of site). So for two high powered radios with 30 dB link gain, this gives a distance increase of 5.6 = 10^(30dB/40) and for one high powered radio and a standard radio where the link gain is improved by only 10 dB, we get a distance improvement of just 1.8 times = 10^(10dB/40)
All the above assumes no electro-magnetic interference from other nearby transmitters, etc.
Outdoors with proper line of site:
32 distance gain 2* high powered radios
3 distance gain high powered radio and a standard radio
Indoors approximation:
5.6 distance gain 2* high powered radios
1.8 distance gain high powered radio and a standard radio
If you want distance, you need the high powered modules at both ends.
Nice analysis - powering up devices in an appropriate order can definitely cause problems such as via the (parasitic) static protection diodes seen on various pins. Presumably this invokes Yveaux's interest in current limiting resistors.
It's a bit unclear how the layout under discussion is actually powered. A cct diagram would be useful here but generally speaking, everything should be powered up pretty much simultaneously, if possible. Regardless the various arduino ccts in existence seem to provide a variety of power paths, many of which are perhaps undesirable. eg supplying power directly to power lines that have on board regulators and hoping that "back driving" those regulators will not cause problems. Likewise various arduinos use the serial chip to provide some power and it's quickly overloaded.
A detailed cct is required to provide any definitive PSU analysis.
@DAN S "...do I really need the IRQ line?"
As far as I can see the IRQ is not used by the NRF24 radio library. I don't ever wire it to the radio.
@hek - just suggesting that you ensure the CT you purchase has some protective measure, such as Zener clamps to limit the Voltage when the secondary is not connected to anything. The ones you linked to look fine.
On the current transformers (CT). Need a little caution with these. If they are energized with no burden resistor and do not have any protective measures in place like zeners, then the output Voltage can be very high. For example if the transformer is one turn to 2000 turns, like Hek's example transformer and we assume the open circuit resistance is 10 MOhms (it's probably higher) and the primary current flow is just one 1 Amp, then the output Voltage can reach 5000 Volts. (1/2000)*10,000,000=5000. The Voltage produced is ultimately moderated by core saturation. I've seen these things produce nice sparks. However Hek's transformer uses a protective measure to avoid this: two zeners in series across the secondary. The linked article under "6. Operation without an external burden."
http://openenergymonitor.org/emon/buildingblocks/report-yhdc-sct-013-000-current-transformer
indicates the Voltage is clamped to +/-22V by the zeners. This is still enough to fry your Arduino ADC, if the required burden resistor is accidentally incorrectly connected. Likewise probably best not to unplug & plug in the CT, while its got power going through the primary. It may be more prudent to hardwire the CT to the Arduino.
V_ANGLE sounds good. With a bit of (floating point) maths, all can be calculated.
@HEK I'll bite:
Use under scores consistently ? eg V_RAINRATE and V_LIGHT_LEVEL
The units to be used here can be clearer:
V_VOLTAGE ---> V_VOLTS
V_CURRENT ---> V_AMPS
Where the base unit is not used - should the name reflect that? eg V_DISTANCE --> V_DISTANCE_CM
Electrical impedance and resistance are not the same thing- suspect resistance is intended here?
V_IMPEDANCE --> V_RESISTANCE
HUM is a bit vague - suggest: V_HUM --> V_HUMIDITY
V_DIRECTION may be confused with an angle or up/down. Could use V_COMPASS_POINT, but that may be confused with magnetic or true north!
V_LIGHT could be confused with V_LIGHT_LEVEL. Could use V_LIGHT_STATUS
V_TEMP while often used, can be confused with a temporary variable? Could use V_TEMPERATURE
V_VOLUME could be confused with audio volume? Could use V_CUBIC_MEASURE
V_HEATER_MODE for V_HEATER?
Could add V_DEW_POINT
STATUS always be used for binary values eg on/off, locked/unlocked?
V_LOCK_STATUS
V_LIGHT_STATUS
V_HEATER_STATUS
The DHT22 spec sheet (a similar device), indicates that you need a single dedicated i/o pin per sensor.
Any one presenting measurements should indicate if they are using Ver 1.3 or 1.4 of the code. There are significant differences in how the timing and ACKing is organized between the two. The OP is using 1.3 and I suspect @yVEAUX is using 1.4 - please correct me if I am wrong on that.
There is no point in trying compare results between 1.3 and 1.4 Any one using 1.3V will be far better off with 1.4.
Yes the improvement to the noise figure is the prime consideration. A signal buried in the noise, amplified by 10 dB, is still a signal buried in the noise. As you point out the NF is defined primarily by the front end amplifier. As long as the front end has reasonable gain subsequent stages will not contribute substantially to the NF. I've incorrectly used the 10 dB figure as the NF improvement.
So using your figure of 2.6 dB, which looks like an appropriate figure but could be higher; then this suggests, It's really a waste of time using the LNA+PA PCBs unless they are used at both ends. In which case you get the benefit of the power amplifiers and a slight receiver improvement.
Any improvement people may witness with just one end having a LNA+PA PCB is probably just because the LNA+PA PCB uses a far better antenna - the rubber duck versus the PCB antennas. In which case you are probably just as better off using these:
https://www.sparkfun.com/products/705
Noting it has 3V3 regulator built in, that may help with power supply sag, that people are experiencing with the PCB modules - requiring capacitors to be added latter. However they are a bit expensive\e.
There are all sorts of magical antenna shapes - a few examples here:
http://www.ti.com/lit/an/swra351a/swra351a.pdf
The PCBs with the zigzag shape
http://www.barefootelectronics.com/nordicc.png
are probably a "meandering inverted F antenna" similar to this one:
http://www.ti.com/lit/an/swra117d/swra117d.pdf
The PCBs with the seven shaped antenna is probably just a 1/4 wave monopole bent to make it less sensitive to polarization?
http://www.barefootelectronics.com/NordicA.jpg
Hard to say what the rubber ducks use unless pulled apart. It's easy to just assume they are all interchangeable. They aren't - they are designed specifically for the frequency to be used. This one is a dipole with the associated doughnut radiation pattern:
