New EntrySat Cubesat

db

#21

Hello Freddy …Great Job !!!Tks


#22

Deployement is delayed to July 3th, 16h25 UTC (Nanoracks info), so EntrySat should start to emit 17h UTC.


#23

ENtrySat have been deployed at 16:24 UTC


#24

We are waiting now your first reports to know if it is alive !!


#25

This is the first scheduled observation after EntrySat starting transmitting. The first results should be in at ~17:40 UTC.


#26

This should be EntrySat! https://network.satnogs.org/observations/792209/

@F5MDY can you confirm it?


#27

Yes it is !!! We are very happy and appeased ! But we can’t decode the beacon because the audio file is compressed and the resultant bandwidth is too narrow to demodulate …


#28

From some recent observations with telemetry frames decoded I found that there are some more frametypes EntrySat transmits. Do you have some more documentation about them or should we just skip them inside the kaitai struct?

We would need to add some simple “switches” as protection against misinterpretations of the frame contents.

Congrats to a successfull launch!


#29

Dear Patrick

You need to filter on SSID : value 6 for the telemetry frame to decode. I use this filter in the Entrysat demodulator to display data. But all telemetry frame are sent to Entrysat Database and Satnogs Database.

I work with the Entrysat Team for other type of telemetry.

Regards


#30

Thanks for that quick answer!
I think you mean “sid” inside the packet. I just added a check on my local instance for “service” in the header. I think Service 3 and maybe Subservice 25 will also indicate telemetry payload. Checking for “sid==6” means we will have to move “sid” into the header, or add another instance.

[..]
  ax25_info_data:
    seq:
      - id: pus_packet
        type: pus_packet_t
  pus_packet_t:
    seq:
      - id: timestamp_unused
        type: u4
      - id: tm_packet_header
        type: tm_packet_header_t
      - id: payload
        type: 
          switch-on: tm_packet_header.service
          cases:
            0x03: tm_packet_t
  tm_packet_header_t:
    seq:
      - id: packet_id
        type: u2
      - id: packet_seq_ctl
        type: u2
      - id: packet_length
        type: u2
      - id: spare_tm
        type: u1
      - id: service
        type: u1
      - id: subservice
        type: u1
      - id: clock_array
        type: u1
        repeat: expr
        repeat-expr: 5
    instances:
      clock:
        value: >-
          (
          (clock_array[0] * 256 * 256 * 256) +
          (clock_array[1] * 256 * 256) +
          (clock_array[2] * 256) +
          (clock_array[3]) +
          (clock_array[4] / 256.0)
          )
  tm_packet_t:
    seq:
      - id: sid
        type: u1
      - id: mode
        type: u1
[..]

#31

Sorry.
I mean SID (not SSID) in the Telemetry frame.
In your Kaitai file :

  • id: sid
    type: u1

#32

EntrySat is changed to follow 44385 in network.


#33

Yeah, ok, got you!
I would like to add something like:

  tm_packet_t:
    seq:
      - id: sid
        type: u1
      - id: tm_payload
        type: 
          switch-on: sid
          cases:
            0x06: eps_packet_t
   eps_packet_t:
    seq:
      - id: mode
        type: u1

Any objections or suggestions?


#34

I have write something equivalent on my working Kaitai file :smiley:


#35

Was able to demod two packets from 99990 EntrySat https://network.satnogs.org/observations/792206/ playback IQ USB about 10k below, using sm_other/G3RUH-BPSK-9K6$ wine soundmodem.exe

1:Fm ON02FR To F6KTA <UI C Pid=F0 Len=34> [11:42:40R]
Ùè$²‡_ÿ‚‹Œl¢°»¿$

1:Fm ON02FR To F6KTA <UI C Pid=F0 Len=34> [11:43:40R]
Ùí$²Ã_ÿ‚Œ‹lóH°÷¿$


#36

Hello Patrick,
I agree with Xtophe. When EntrySat is in visibility of Toulouse, our ground station ask for some tests. You see the acknowledgment of these telecommands. You can also receive sometimes an unmodulated carrier, used for calibrate our receiver … so you need to filter !!
73, Nicolas


#37

Heh, yeah, ok, but filter for what? Only SID==6?


#38

To be very rigorous, you should detect select valid packet with

in the packet header :
id: service = 3
id: subservice = 25

in the packet itself :slight_smile:
id: sid = 6

The CRC is checked by the AX-25 routine ???

I dindn’t understand how the frame decoding is performed ?? Is it done localy by the satnogs client ? Or on the satnog server … I checked the audio file in the server (oog files) and the audio bandwith is near 8kHz … it is too narrow to demodulate a 9600 BPSK signal …


#39

It is done on the SatNOGS node by the client, using the gr-satnogs OOT GnuRadio module. You can find the flowgraph here:

I am just checking for SID in the latest decoder now.


#40

From this tweet:

1 99999U          19184.68402778  .00085189  00000-0  13880-2 0 00006
2 99999 051.6417 279.4339 0005689 074.7314 052.3234 15.51621104177776