YAPP idea - MOB alert system

The first victim unit...

67w6.jpg


First draft of the PCB seems ok. The spaces for components not fitted that can be seen are for Nigel's LED.
 
Last edited:
AngusMcDoon said:
The first victim unit...

67w6.jpg


First draft of the PCB seems ok. The spaces for components not fitted that can be seen are for Nigel's LED.
Click to expand...

There seems to be quite a bit of headroom in that case. Is that the most suitable profile available? The thicker it is the more likely it is to be forgot to wear it.

I guess we could trim it done a bit.
 
Graham_Wright said:
There seems to be quite a bit of headroom in that case. Is that the most suitable profile available? The thicker it is the more likely it is to be forgot to wear it.

I guess we could trim it done a bit.
Click to expand...

It's finding an off the shelf case that is suitable for a reasonable price that limits the choice. The case is 24mm thick - about the same thickness as a packet of 20 cigarettes. The other dimensions are smaller than a cigarette packet.
 
And now the first central receiver circuit board next to its box. Still waiting for the lids. The buttons are just temporary...

xs0p.jpg


This gives a better indication of the thickness of the victim unit's proposed box...

ty0b.jpg
 
Last edited:
nigelmercier said:
What a nice chap you are.

It occurred to me that these could also be used for "kiddie monitors".

Presumably the victim units transmit their ID? Did you use Manchester coding?
Click to expand...

The victim unit transmits its address - 1, 2, 3 or 4. This is set in EEPROM at flashing. There is plenty of program space and air bandwidth to do something more sophisticated if anyone is so inclined. Anything clever like Manchester coding, retries on fail, collision arbitration etc. is done by the RF chip.
 
Last edited:
nigelmercier said:
So you just SDO the data to the TX board? I've recently bought a few 433MHz pairs, but I cant find any datasheets. I wonder if the I/O protocol is the same.
Click to expand...

I doubt it's the same. It is a fairly complex SPI command set described here...

http://www.nordicsemi.com/eng/conte.../file/nRF24L01_Product_Specification_v2_0.pdf

Fortunately there is an open source library for controlling this chip. I don't use much of its capability other than sending/receiving data and setting transmit power. Everything else is library defaults.
 
Last edited:
AngusMcDoon said:
It's finding an off the shelf case that is suitable for a reasonable price that limits the choice. The case is 24mm thick - about the same thickness as a packet of 20 cigarettes. The other dimensions are smaller than a cigarette packet.
Click to expand...

Angus,

FWIW I'm using something similar to this (see below) for the victim unit which I am making. I'm waiting for delivery but it cost £2.49 from Amazon though there are several different types available.
I like the fact that it is waterproof, floats and in particular has a lanyard. I use one for keys and cash when I'm out on my bike and it's stood up to nearly daily usage for a few years.

http://www.dive-logs.com/productdetail.jsp?ProductCategory=24&ProductID=224

Just a thought.
 
Last edited:
I was thinking about that as I am making a new Navigatrix/Opencpn navcomputer. I have Seatalk on a serial line input to the computer (from our home made remote control from the autopilot), as well as NMEA which will come out as a waypoint but not an MOB alarm. I have a c code to parse the Seatalk so it could take some special action.
 
Just a quick update on progress for dedicated followers of YAPP. Way back in the thread Andrew G wrote this...

Andrew G said:
According to Thomas Knauf (my intepretation) to start MoB one should send:

82 A5 40 BF 92 6D 24 DB
6E 07 00 00 00 00 00 00 00

I had to send it more than once for it to work.
Click to expand...

At the time I had not tested my Seatalk MOB integration on a real Seatalk network, but yesterday I did. I am sending the MOB message just once (with automatic retries if the network is busy in the Seatalk sending code) and it worked every time. I tried it about 50 times until I got cold. Here it is in action...



That's version 1 of the main receiver PCB. It has a component poking out of it because of a cockup where a component's footprint in the DesignSpark library is wrong - 2 legs transposed, so version 2 is winging its way from the factory. Version 2 also has a less important cockup where a component's silkscreen on the board is upside down (another DesignSpark library error). However, that mistake is not functional, just a trivial mistake in the on-board assembly guide documentation, so can be lived with except for anyone who wants a bare PCB for self assembly. They will get version 3 of the PCB.
 
AngusMcDoon said:
It has a component poking out of it because of a cockup where a component's footprint in the DesignSpark library is wrong ...
Click to expand...
BTDTGTT-S! Now I always work from my own versions of components in DSPCB, and double check the footprints against the data sheet from the actual manufacturer.

I'm definitely going to steal your SeaTalk code :)
 
The first lids arrived today...

hzcu.jpg

4o2q.jpg

xw49.jpg


This is still the faulty first version of the main PCB with one of the components bodged on with wires. Waiting to the next version to arrive.
 
Last edited:
You must log in or register to reply here.

Other threads that may be of interest

P
Old AGM battery.
Replies
9
Views
307
samfieldhouse
samfieldhouse
A
Angelo Lavranos Holiday 34 / L34 by Robertson (SA) - grade of aluminium of mast
Replies
3
Views
205
Neeves
N

Share this page

Top