Archived Forum

I should swap the car!

I guess the r.f. from the Mk2 is overloading the receiver in the car. You might be able to get an idea of the signal strength if you look at how MartinR's GLCD signal strength meter works, and if there's enough signal at your Mk2 load (use a multimeter, not a GLCD!), you could try turning down the Mk2 transmitter - details are in section 11 of the RFM12B manual, TX Configuration Control Command.

It's probably too late to suggest using 868 MHz  for the link, which would take it further away from the car key (but it still might not cure the problem), and I'm assuming it's not possible to run a twisted pair of telephone wire or similar and not use the r.f.

What make/model car do you have?

Paul

Many thanks for the replies.

Robert. You are correct in your assumption that it would not really be practical to run a twisted pair. I have had some difficulties with the range of transmission but I could try and reduce the output as suggested. You seem doubtful as to whether the 868Mhz module would work but it might be worth a try.

Paul. The car is a Toyota Rav 4 D4D

I've done a quick Google search and it appears that your key is susceptible to any strong r.f. transmissions in the vicinity (police radios are cited as one problem area).

I was doubtful even before I found that because the key at 315 MHz should be well outside the sidebands of the RFM12 even at 433 MHz, so my presumption is the car key receiver has absolutely no front-end selectivity at all, so moving even to 868 MHz might achieve nothing.

There are two things you can try:

1. It might actually be worth trying the link on 868 MHz in software anyway, with the 433 MHz modules. The range is severely limited but they do operate - though your remote load probably won't work. If it still jams the car key then, it's almost certainly not worth changing the modules to 868 MHz ones. It the car key does work, then, and if it's easy to swap the modules, it might be worth swapping the modules to get the load working again. (Of course, the higher power might mean the key stops working...)

2. I think you've got to find out if you can turn down the RFM12B transmit power far enough on 433 MHz (or 868 if you swap the modules) to allow both the key and your remote load to work.

I'm not particularly hopeful for either, unfortunately.

Many thanks for the reply and advice.

I have reset the transmitter module in software to 868 MHz as suggested, and the car keys seem to work OK. I then reset the receiver to 868 mhz and it worked up to 6 feet from the transmitter. I am not sure whether the keys work because of the changed frequency or just because the range is so short. I think it may well be worth changing to 868 MHz RFM 12B to see if the frequency is causing the problem. Do you happen to know if I can get away with just changing the transmitted RFM 12B  and changing the frequency on the receiver module in software, or do I need to replace both of them. 

Many thanks.

FWIW, I've only ever used the 868 MHz RFM12B modules.  

With my Mk2i rev5 code, the RF chip spends most of its time asleep, so I'm surprised to learn that it can block out randomly timed transmissions in a different system.  Increasing the refresh period might be an easy fix, and also using as slow an anti-flicker mechanism as possible.  The conventional dual-threshold AF algorithm in Mk2i rev4 cycles more slowly than the single threshold "no cal" one in rev5.  

The radio-key for our Peugeot 107 has never misbehaved, nor (thankfully!) have any of our neighbour's cars ended up being stranded on the adjacent driveway.

The modules are different - they are tuned for the respective band, so I'm pretty certain that you'd need the receiver to be an 868 MHz one, and most likely the transmitter too. What we can't tell is whether the frequency, the low power (because it was working out-of-band) or both was allowing the car key to work. If you are going to change the modules, I'd change the receiver first and see what range you get. I haven't noticed numbers for the performance on the 'wrong' frequency, so I've no idea whether lowering the power setting will have the same effect as detuning the hardware (which is in effect what you've done).

Have you tried turning the power down on 433 MHz? That should be a relatively easy software change in the transmitter only.

I think outside of the US, they use 433.92 MHz for key fobs, not 315 MHz.  I've parked my Prado (which probably has the same unit as your RAV4) in two locations now where I had to lock/unlock the door the old fashioned way.  

An interesting article here on just how widespread the problem is:

http://www.ofcom.org.uk/static/archive/ra/topics/low-power/document/rake...

Thanks for the advice everybody.

I have looked at the above link and just realised just how big this problem is. I think I will leave the rf side of the system disconnected for now, so as not to cause any problems,and revert to the standard reliable Mk2. I will then do some more testing and hopefully come up will a solution. I will keep you updated. In the mean time, any other ideas would be appreciated.

Once again thanks for the help.

I have an Audi key here which is clearly marked 433MHz. I just tried it near the signal strength meter and, if you press and release a button, it gives a single data burst of about 300ms. If you hold the button it transmits continuously.

A Land Rover key emits 4 bursts over about 400ms and again if you hold the button it repeats continuously.

This sort of signal shouldn't be blocked unless your diverter is transmitting more often than the key transmit time.

Maybe the Toyota key has a longer transmission time? If not then I would say that the diverter is transmitting too often.

edited to say: the channel occupancy restrictions on the 868MHz band are even more restrictive than the 434MHz band so it's probably not a good idea to switch to that one.

I wonder if Toyota's rx state machine is less robust than most.  Perhaps it sees something that it thinks is for it, then gets lost when it turns out not to be, and takes way too long to reset itself to idle state.  It may even be a deliberate anti-tamper "feature" of their receiver to thwart brute force attacks.

Once again many thanks for the advice.

Very little sun yesterday so could not do much testing. However from what I could do the key blocking seems to be worse when the rf load is flickering. At other times it may sometimes work if I persist. Do you think it is worth trying anti flicker mode or would this made the whole system less efficient? I have tried contacting Toyota to establish the frequency of the key, but they just referred me to the dealer who doesn't have a clue!!!

Robin. Could you please let me know how to increase the refresh rate and adjust the anti flicker rate, if possible.

solar: yes, I would definitely recommend running your Mk2 system in anti-flicker mode, otherwise you could be sending out RF messages every few mains cycles.  Anti-flicker mode is no less efficient than normal mode; it just waits until a longer burst of power can be sent to the dump load.  Both output-modes work within the permitted energy band that's allowed by the meter.  With the Mk2i_rev5b code, you can enable AF mode at line 231:

boolean runTimeSelectionIsEnabled = false;                                          
enum outputModes outputMode = ANTI_FLICKER;                                                   

Hopefully that will cure the problem so no changes to the AF code will be necessary.  But in case such changes are necessary (and because I've already typed it before re-reading your post), here goes ...

Robin. Could you please let me know how to increase the refresh rate and adjust the anti flicker rate, if possible.

In my Mk2i_rev5b sketch, the refresh rate is set at line 176.  Each mains cycle is 20 mS, so 50 cycles is one second:

const int noOfCyclesBeforeRefresh = 50;
 

NB. The similar looking statement at 158 does not appear to be used, i.e.

#define REFRESH_PERIOD 1000 // max period (ms) between RF messages
 

***

When running in AF mode, the switching rate for the dump load is set at line 286:

const int postMidPointCrossingDelayForAF_cycles = 25; // in 20 ms counts
 

Because the AF algorithm in Mk2i_rev5 only has one energy threshold, it needs to switch the load on or off a certain time after each mid-point crossing has occurred.  If you wanted to reduce the switching rate further than this mechanism allows, you may be better off using the original 2-threshold AF algorithm.  For this, in a multi-load RF-enabled Mk2 environment, you would need to either:

1. Replace the 1-threshold AF algorithm that's in rev5b by the original 2-threshold AF algorithm from rev4, or

2. Port the RF and multi-load capabilities from rev5b into a copy of the rev4 code. 

Given these two options, I would expect the former to be much the easier.  Hope this helps.

Not much sun today but just installed anti flicker mode as outlined by Robin and the keys certainly seem to work much better now. I will do more tests tomorrow (if we get more sun) and report back. I can't be certain, due to lack of power, but I think you  may have solved  my the problem.

Many thanks to everyone.

Excellent.  Operating a burst-mode diverter system in 'Normal' mode is fine in principle but is not always suitable in practice, as you have found.  Some kind of anti-flicker system is needed. 

With your on/off messages now occurring at around 1 Hz, and with RF only being transmitted in very short busts, I think your car-key system should work fine for the vast majority of key-presses.

If you wanted to check the operation when more power is available, surplus power can easily be simulated by running an extra wire around your CT.  I've shown this principle in operation at http://www.youtube.com/watch?v=MopB2NAU4TU

Had some sunshine today so did quite a lot of testing. The car keys now seem to work well, but they do sometimes miss now and again, but only when the r.f. load is flashing. I don't think you would even notice this if you weren't looking for it.

Fortunately no one else in the street seems to have noticed a problem, so I think I am now in the clear.(or perhaps it was just my car)

Many thanks for all the help and suggestions.

Maybe you should replace your key-fob batteries now, after all that testing :D

Turns out is is not just your car.

I can't even have my emontx V3 turned on with my subaru impreza. 

The key fob just wont work at all.

Can anyone advise how I can try the above type of solutions with the emontx base station?

thanks

I'm afraid your terminology is awry. The emonTx is a measurement node, the NanodeRF or Raspberry PI is a Base node. Is it just the emonTx that is causing the trouble?  What frequency are you on?

If you're using the default sketch, you could first try extending the period between measurement samples. it's line 46:

const byte TIME_BETWEEN_READINGS= 10;                                   //Time between readings

that's 10 s and ought to be enough for your car keys to work in between transmissions. You'll lose some accuracy if you stretch the time too far, but you may find an acceptable balance.

Sorry you are correct. I am new at this. It is the base node not the emontx. And I have a Raspberry PI version

I have the 433 version

From what I can gather, 433 MHz is also the frequency used by your car key, but I can't find a definitive statement to confirm that.

Are you now saying that when you turn the Raspberry Pi off, but leave your emonTx working, your car key fob works normally, or were you correct to begin with and it's when you turn the emonTx off that the car key fob works normally?

I'd be more inclined to believe the latter. As I wrote above, the emonTx transmits every 10 s and I can believe that might not leave a big enough gap for the car key to work, whereas I think the RPi should only be transmitting the time once every 30 s or thereabouts on the assumption that you have an emonGLCD (I'm no expert on the RPi), and that shouldn't be enough to block your car's locking system. If turning the RPi off cures the problem, I think you need to make sure it's not transmitting continuously. To the best of my knowledge, no-one has reported that before, and it sounds as if there's something seriously wrong with your RPi.