Re: [Discuss-gnuradio] The PLL for the burst signal

[Jesse Reich]

Hi Vicfield,

I actually work on the ground system that receives these signals. They are distress signals from different beacons: EPIRBs (boats), ELTs (planes), PLBs (hikers or anyone who wants a handheld device) that are captured or relayed through satellites to the ground. This allows rescue authorities to locate people in distress. These beacons are actually part of an international system called SARSAT (Search and Rescue Satellite Aided Tracking). Or Cospas-Sarsat (Cospas is a Russian acronym)

http://www.cospas-sarsat.int/?lang=en

This website provides a vast array of information on the beacons, satellites and ground systems. The technical documents (T-Docs) would be most helpful. Particularly C/S T.001 - Specification for Cospas-Sarsat 406 MHz Distress Beacons (I see Marcus provided a link already but here is a newer version).

http://www.cospas-sarsat.int/images/stories/SystemDocs/Current/CS-T001-DEC-2016-Corr-1.pdf

I can certainly help out if you'd like more info. I actually tried to build a beacon decoded in GRC about a year ago but was never able to get it working. The signal is somewhat difficult as it contains (going off of memory here) 160 ms of pure unmodulated carrier, then 15 bits of bit sync, then 9 bits of frame sync. As Vitt mentioned, there is a "test" mode. The frame sync is inverted. See below. 

2.2.4.1 Bit Synchronization A bit-synchronization pattern consisting of "1"s shall occupy the first 15-bit positions. 

2.2.4.2 Frame Synchronization A frame synchronization pattern consisting of 9 bits shall occupy bit positions 16 through 24. The frame synchronization pattern in normal operation shall be 000101111. However, if the beacon radiates a modulated signal in the self-test mode, the frame synchronization pattern shall be 011010000 (i.e. the last 8 bits are complemented). 

Additionally, the BPSK modulation index of +- 1.1 rad makes things a bit more difficult as well. 

Good luck, please let me know if there's anything I can do to help although keep in mind I'm an Aerospace Eng not an EE!

Jesse 

On Tue, Apr 25, 2017 at 8:59 AM, Vicfield Medici <address@hidden> wrote:

Hello, Victor:

Thanks for your information,
I exactly tried to decode the file with the real EPIRB signal from a PLB,
although I’m pretty suspicious about that is beyond me too much…

But it is really surprised me that what you said:
The signal "trigs" detecting is too complicated to implement alone!?
Now I’m really confused, have you any clue about that?

Again, thank you so much.

Regard,
Vicfield.


Vitt Benv wrote
> H
> ​i Vicfield!
> another info for you: are you palying with a "real" EPIRB signal or with a
> "test" signal?
>
> In the first case.... be sure that the signal cannot reach the open space:
> the signal "trigs" an expensive and complicated stuff, actulally it's
> starts a S&R process with a lot of people involved...
> In the second case, if I recall right, the signal it's sent at full power
> but "reversed". I dont recall if bit-order reversed or bit-complemented,
> sorry!
> In this manner it's possible to do tests ( and this is part of my job ;-)
> ) on EPIRB. For this I had a Futronic GMDSS testset.
> Hope that this ca help you...
>
> Ciao,
>
> Victor
>
> Il 24 apr 2017 18:07, "Vicfield Medici" <

> address@hidden

> > ha scritto:
>
>> Hi,
>>
>> Really thank you all.
>> I was read the specification of EPIRB and researched something about
>> that,
>> but it’s seems some error about that. I will attach the GRC what I tried.
>>
>>
>> > So, a PSK that can only take values of +1.1 and -1.1, relative to the
>> > "idle" carrier. Bit rate is 400b/s, so that makes it a 800 S/s PSK
>> > symbol rate (Manchester-encoding happening in between).
>>
>> Marcus, thanks for your advice.
>> I set the baud rate for 400 bits/sec.,
>> but does it related about the PLL or Time Synchronization?
>> I thought the Manchester decode is the part of line code
>> and I should take that later?
>>
>>
>> > About frequencies pay attention that there are more than a single
>> (406.025
>> > MHz)
>> > frequency.
>> > In my direct experience there's also 406.028 / 406.039 MHZ in use. So
>> also
>> > tuning
>> > has to be on the right frequency.
>>
>> > Current NTIA spectrum documents are here:
>> > https://www.ntia.doc.gov/page/federal-government-spectrum-us
>> e-reports-225mhz-6ghz
>>
>> Thanks a lot, Vitt and Ron.
>> In fact, I just testing the file was recoded with my PC,
>> so I guess it’s not a trouble now, but still thanks.
>>
>>
>> Here is the GRC I tested below, it refer the GRC from  here
>> <http://gnuradio.4.n7.nabble.com/Tutorial-on-BPSK-bursts-td58484.html>
>>  by
>> Andy Walls.
>>
>> Again, Thanks and appreciated for any help.
>>
>> Thanks,
>> Vicfield.
>>
>> 512K_test_.grc
>> <http://gnuradio.4.n7.nabble.com/file/n63620/512K_test_.grc
> > >
>>
>> BTW, how can I upload the file like "Download Attachment"?
>>
>>
>>
>> --
>> View this message in context: http://gnuradio.4.n7.nabble.co
>> m/The-PLL-for-the-burst-signal-tp63604p63620.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>

> Discuss-gnuradio@

>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list

> Discuss-gnuradio@

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





--
View this message in context: http://gnuradio.4.n7.nabble.com/The-PLL-for-the-burst-signal-tp63604p63635.html

Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--

Jesse