Waterproof remote for electric surf - HC-05 lost connexion check

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

I've made with succes a BT remote and reveiver to drive 120A ESC.

The emitter is made of a ATMEGA8A (internal 8MHZ), a HC- board and 4 HAL effect sensors (it will be driven by a magnet in a waterproof case).

The receiver drives a PWM output and receive by BT the level (7 differents states).

Everything works very well. I've checked the signal with a scope and the signals are very precise (from 1ms to 2 ms max.)

I want to securise the working by adding a BT connection check because, when i drive to the maximum (2ms) and unplug the remote supply, the receiver is locked on 2ms.

That means, when i will fall of my surf, it will continue untill there is no more battery. Good luck for me, i'm quite a good swimmer smiley.

It's because the receiver always check the USART reception and gets locked on :

while (!(UCSRA & (1 << RXC)));					/* Wait until new data receive */

So, when the connection is lost, it waits for a byte that never comes.

 

Does someone knows how to make it safe ?

 

Thank you

 

This topic has a solution.

I use ATMEL STUDIO 6 and work now on ATMEGA328p

Last Edited: Sun. Aug 25, 2019 - 07:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I don't remember wrong those modules should have pin in them which can be used to figure if there is active connection or not.

 

You should propably use interrupt based uart receive, that way the reception won't block program from running, always store a "timestamp" from timer when byte is received via uart, then compare that "timestamp" to current value of timer register to see if there have been too much time elapsed since last byte receives and shutdown the motor.

Last Edited: Thu. Aug 22, 2019 - 03:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like the problem is your power supply design since the AVR is locking up your software check is useless.  The WDT may work, but if the AVR is locked up who knows.

 

My Son and I have several R/C trucks and cars and we use ESC's with 120A ratings as well.  I can tell you that the power surges and dips off the main battery are brutal to say the least.  I suspect thats what is causing your design to have issues.  Post a schematic of your device and we can give some ideas.

 

With watercraft, regulations here in the states say that the operator(driver) of the watercraft be tethered to an emergency power cutoff(this is for both electric, and fuel powered craft) so that in the case of operator discharge(falling overboard, falling off the craft) the emergency power cutoff is pulled and the motor shuts down.  This cutoff prevents an uncontrolled craft from heading into innocent swimmers causing injury or death from the craft/propeller, etc.

 

Saves you from a long swim too wink

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Am I reading/interpreting this correctly? You are expecting a bluetooth radio link to continue operations when one end gets dunked underwater?

 

ps. This paper may be of assistance.

 

https://www.ncbi.nlm.nih.gov/pmc...

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Thu. Aug 22, 2019 - 03:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft wrote:

Am I reading/interpreting this correctly? You are expecting a bluetooth radio link to continue operations when one end gets dunked underwater?

 

i believe his trying to recover safely from a state when the bluetooth link disconnects suddenly.

 

and the small sample provided from code indicates his receiving uart data by polling, and then most likely putting that directly to pwm register or so, now if the link drops the motor will continue running at the speed it was running before disconnect, since his AVR is polling for next value which will never come.

Last Edited: Thu. Aug 22, 2019 - 03:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

reptooyep wrote:
Does someone knows how to make it safe ?

 

I stress you read post #3 carefully.  THe only true way to protect you, and others around this thing is a simple ankle tether like surfers use to a 'kill switch'. 

 

valusoft wrote:
Am I reading/interpreting this correctly? You are expecting a bluetooth radio link to continue operations when one end gets dunked underwater?

I don't think so.  The OP is trying to come up with a solution should he fall of this thing and it speeds off and loses radio connection.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So he wants to cut off the engine when he falls off with the bluetooth thingie.  Yeah sounds like the ankle thingie would be cheaper/simpler and not need batteries. cheeky

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are wondering about connection loss in water, it's because how RF travels through different materials. Water dielectric constant is not ~1 like air. Its if I remember correctly, 80 at room temp. Your path loss will go up when you place different materials in the path of the transmission. ie water. 

 

p.s. this paper might also be of some assistance as well:

https://www.am1.us/wp-content/up...

and for further reading on microwave:

https://www.microwaves101.com/en...

 

Cheers

 

Cheers,
Jesse_G an EE writing firmware...what could go wrong...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The OP is not trying to keep comms going.  read the OP #1:

reptooyep wrote:

That means, when i will fall of my surf, it will continue untill there is no more battery. Good luck for me, i'm quite a good swimmer smiley.

It's because the receiver always check the USART reception and gets locked on :

while (!(UCSRA & (1 << RXC)));					/* Wait until new data receive */

So, when the connection is lost, it waits for a byte that never comes.

Once the OP falls off...that craft is already long gone from BT range.  The OP wants to sense that loss of comms.

 

One way to do this is simply to constantly send bytes and in the ISR reset the WDT.  If comms is lost the ISR never fires and the Dog barks.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
//------USART-------------------
uint8_t kbhit(void)
{
//return nonzero if char waiting  polled version
    uint8_t b;

    b=0;
    if(UCSR0A & (1<<RXC0)) b=1;
    return b;
}

//-----------------------
int getchar(void)
{
//polled version...
    uint8_t c;

    while(!kbhit()) {}; //wait for char
    c=UDR0;             //get char from usart
    return c;
}

A simple polling of the RCXO bit will tell you if data is waiting (kbhit() function above) will prevent blocking in the USART read function() similar to the above, by only calling USART_read() when data is waiting.

This way you can pole for data, or test for loss of signal without blocking!!!

Jim

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all

It sounds good and simple... i'm not a code "raving lunatic".

I love programming AVRs but it's not my job, it's just for fun, so, i do my best but sometimes need help.

I'll try this tonight and will post the results.

 

PS my propeller is a turbine made of 50mm stainless steel tubes, so no dammage with the inpeller.

I use ATMEL STUDIO 6 and work now on ATMEGA328p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

reptooyep wrote:
PS my propeller is a turbine made of 50mm stainless steel tubes, so no dammage with the inpeller.

A hand, or foot can still get in there....not the point, not going to get into an argument over it....

 

Anyway....

 

You're not in the USA, but Europe.  While I am not sure what the EU rules/laws are regarding personal watercraft of any kind are, I would bet that they want some sort of 'kill switch' for your craft.  The fines here can be pretty severe(here in NYS they actually patrol looking for these'kill switches' and that they are set up properly too.)  If the EU has the same protocol you may need to add this feature anyway.

 

There are some good ideas presented on the software side in the thread already, and a sure fire/simple method to do what you want.

 

Up to you.  Post a link to a video of this thing too!

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't find any law in france for this kind of device, as they are very few of them. Anyway, i want to make it safe for everyone.

I have to find examples of interrupt receive.

I can also make a timer which send a byte to the emitter each second and receive the echo byte. If he don't receive it, it disable the motor.

I use ATMEL STUDIO 6 and work now on ATMEGA328p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ki0bk,

Instead of  being locked on :

while (!(UCSRA & (1 << RXC)));

Now, i'm locked on :

ki0bk wrote:

while(!kbhit()) {};

 

The result is the same but i continue searching this way

I use ATMEL STUDIO 6 and work now on ATMEGA328p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Strange thing :

When i disconnect the emitter, the PWM output stay at its value and becomes high after 15 seconds which will stop the motor but it's hard to explain why...

This appens only when i unplug the emmitter. If i power on the receiver alone, it stays at 1ms output... forever !!

And 15 sec is far too much. If i can reduce this time , it's ok.

I use ATMEL STUDIO 6 and work now on ATMEGA328p

Last Edited: Fri. Aug 23, 2019 - 12:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

reptooyep wrote:
Now, i'm locked on :

ki0bk wrote:
by only calling USART_read() when data is waiting.

Only call your USART_read if kbhit() returns nonzero value!  Or in other words, there is data in the USART waiting for you.

....
if(kbhit()) c = usart_read(); //get data only if char has been received!
//poll for shutdown or anything else important
.....

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, there should be another problem elsewhere, i'll continue searching.

 

I use ATMEL STUDIO 6 and work now on ATMEGA328p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if you send data with certain interval you could implement timeout feature with timer interrupt to shutdown motors incase the bluetooth link is lost.

 

this code is just to give you an idea how it could be done, it wont compile as it is.

 



volatile uint8_t timestamp = 0;

/* timer interrupt 1 ms period */
ISR(TIMER_INTERRUPT){	
	if(++timestamp == 254)
		timestamp = 0;
}

int main(void){

	//your init codes
	
	while(1){
	
		if(khbit()) {
			//read Usart data register and do something with the data
			timestamp = 0; // <- Reset counter
		} else if(timestamp > 100) {
			//shutdown motor, connection was lost
		}	
	}
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
if you send data with certain interval you could implement timeout feature with timer interrupt to shutdown motors incase the bluetooth link is lost.

 

Like the WDT I suggested?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

JoniS wrote:
if you send data with certain interval you could implement timeout feature with timer interrupt to shutdown motors incase the bluetooth link is lost.

 

Like the WDT I suggested?

 

JIm

 

Yeah, essentially same idea.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trying to get any government issues requirements for the EU is proving difficult.  But searching through the various vendors of different types of personal watercraft all have basically the same information....THey all have the lanyard type manual engine cutoff switch I mentioned, and they all say that their products are in compliance with European regulations for the watercraft.

 

So that being said you could kill two birds with one switch....be in compliance with regulators(saves you a hefty fine potentially), and also solves your issue with the unit accidentally locking up in a state where the board takes off with no way to control/stop it.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Trying to get any government issues requirements for the EU is proving difficult.  But searching through the various vendors of different types of personal watercraft all have basically the same information....THey all have the lanyard type manual engine cutoff switch I mentioned, and they all say that their products are in compliance with European regulations for the watercraft.

 

So that being said you could kill two birds with one switch....be in compliance with regulators(saves you a hefty fine potentially), and also solves your issue with the unit accidentally locking up in a state where the board takes off with no way to control/stop it.

 

Jim

 

I'm almost certain "Dead man's switch" is required if one wants to follow EU regulations, atleast in finland it is required. Like you said every single watercraft commercially sold does include that, and its for a reason.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
Like you said every single watercraft commercially sold does include that, and its for a reason.

 

Yes.

 

Let me clarify this statement:

jgmdesign wrote:
be in compliance with regulators(saves you a hefty fine potentially),

 

Before the OP barks that his device is not for commercial sale, but private use only.  While I am not sure about the EU(but I suspect it will parallel what happens here in the USA), should you operate this surfboard in a public place, it must be in compliance with any regulations regardless of financial intent...private use, or for sale.  As I wrote earlier, we have patrols around here checking for these safety mechanisms and if they find that they are missing/tampered with etc, they can confiscate the craft, and you will have to pay some expensive fines to get it back. 

 

Now with regards to your design issues with lockup, I suspect you have both a hardware design issue(surges/dropouts), and a software issue causing the system to lockup the way it does.  I suggest that you post your code for both the transmitter and receiver so we as a group can find whats going on.  Post a schematic for review as well.

 

If your code is a large file, then post the main.c file as an attachment.

 

No one here is trying to discourage your project.  WE are all looking to make it as safe as possible for you....and those around you as well.

 

JIm

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

A "Dead man's switch" doesn't exclude to add a software solution, so that i'll have a double safety.

I use ATMEL STUDIO 6 and work now on ATMEGA328p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP doesn't seems to be listening to the "kill cord" advice and is determined to stick with his initial Bluetooth idea.

 

"Kill Cords" and their use are mandated for a reason; I remember this sad story from some some ago:

https://www.theguardian.com/uk-news/2014/nov/10/padstow-speedboat-accident-inquest-victoria-nick-milligan

 

Relaying on software as a "safety device" brings in a whole host of requirements of which I know very little, but enough to know I should stay away from it because even the Big Boys sometimes get it wrong. (Tesla Motors, Toyota & Boeing etc.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

reptooyep wrote:

Hi,

A "Dead man's switch" doesn't exclude to add a software solution, so that i'll have a double safety.


Of course. I would have both as well.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks ki0bk and joniS,

Both of you have given me the hints to success.

I've had bad time tuning the timers on each board to find the good sync.

The emitter send data each 2.5ms and the receiver count  1.3ms cycle with a timestamp of 4 and force the PWM at minimum value.

It's now very precise and responsive.

Thanks a lot for your good advices

I use ATMEL STUDIO 6 and work now on ATMEGA328p