And structure doesn't need to change. The comment is library comment is wrong. The extra call is not required. Both functions check the same state. Yes, it may mean future library updates may cause breakage, but it looks like its being used as an optimization anyways. Besides, when the examples change to reflect the code comment, then you should be concerned. Until then, monkey see, monkey do. It can look like this:
void loop()
{
buflen = VW_MAX_MESSAGE_LEN ;
if (vw_get_message(buf, &buflen)) // check to see if anything has been received
{
blinkLed(redLedPin,1,250);
if( buflen >= 2 ) {
power = word(buf[1],buf[0]);
power = power / 100;
count++;
Serial.print(power,1);
Serial.print("kwh : count:");
Serial.print(count);
Serial.print( "errors: " ) ;
Serial.print( error ) ;
Serial.println("");
power = 0;
} else {
error++ ;
Serial.print( "did not receive enough data; error: " ) ;
Serial.print( error ) ;
}
}
}
I am wondering if its getting hung up an an outside transmission at the same bitrate ( I am testing in my house with all the neighbours having a different brand of garage door opener, a lot of them on 433 mHz the same as mine ....???
It looks like you have the same hassle with knowing how long to test a change before you know if its fixed or not.
I think I might slow the bitrate right down both ends to get away from the garage door stuff for testing..
I slowed it to 1100 but it hung up within a couple of minutes ...???
I am using a cheap switch mode power supply, I am going to try another type this morning, and I have even tried moving my celphone away from the unit under test, really clutching at straws now..
I have just noticed that neither of us have the
if (vw_have_message() )
that codingbadly suggested . I think I will study the VW pdf again ( RTFM )
I know for instance that I will be receiving 20 bytes every message, so perhaps I can get it to check buflen is 20, but then again thats what VW is doing when it sends buflen anyway....
As I only need the loop to do anything after getting a message ( my displays are latched, not multiplexed ) I am trying the instruction
vw_wait_rx()
which is blocking, the trouble is I might only know by tonight really if its working ...
Boffin1:
I think my problem must have been a noisy power supply ! ( I was using a JUS mains adaptor that the supermarkets sell )
Its been working 20 hours OK now since I changed the PSU (and made the loop wait for a new message wit the blocking VirtualWire wait instruction.)
Good luck with yours
Congrats!
But in fairness, you did have multiple issues with the code and you can now react to various unexpected conditions which the previous code just glossed over. So its a win-win!
Hopefully my code for these projects will be as good as it gets now, it has been working in 4 other projects with no trouble as it was, warts and all, but with decent power supplies.
Its all a learning curve, for instance it was only when I looked at a photo I took to post here of the UUT running, that I saw my celphone on charge 200mm away, I have been caught out with that before !
This unit will be fitted to a scoreboard on the far side of a field, so I don't have to worry about any interference from garage openers or celphones, but I couldn't take a chance. This should have gone out last week....
By next week I should be working on one project at a time, --- bliss