Static Logging Settings - 1 second setting

I am logging static data but could not find setting to set it to record at 1 second intervals. I have tried 1hz, 5hz but the recording interval is smaller than 1 seconds. In the sample RINEX output below it’s 46.704

1 1
19 8 28 5 54 46.7040000 0 5G19G 6G 2G13G 5
23143238.376 3 -2712.202 25.000

23440293.888 -197.537 28.000 23440289.881

19 8 28 5 54 46.8040000 0 5G19G 6G 2G13G 5
23143289.758 3 -2712.022 25.000

23440297.640 -197.729 28.000 23440293.712
3 -145.353 16.000
23519963.229 1643.978 26.000

Is there a setting that would make the logging file record at 1 second intervals?
I have several other non-emlid units and I would like to know if this will affect post processing results if time intervals are not synchronized ?
The other units are currently in the field so I am not able to do a full test.
Thank you.

Can you post a simple report, when unit is set to 1 hz under RTK Settings?

Sorry, still new to the unit. What is a simple report? Is it the RINEX file? Can’t seem to upload it to the forum. A section of the RINEX file is as follows:

2.10 OBSERVATION DATA M (MIXED) RINEX VERSION / TYPE
*RTKCONV 2.4.3 b33 20190828 060151 UTC PGM / RUN BY / DATE *
*log: D:\Downloads\raw-201908280554-UBX\raw_201908280554.UB COMMENT *
*format: u-blox COMMENT *

  •                                                        MARKER NAME         *
    
  •                                                        MARKER NUMBER       *
    
  •                                                        OBSERVER / AGENCY   *
    
  •                                                        REC # / TYPE / VERS *
    
  •                                                        ANT # / TYPE        *
    
  • -3184537.2483 5285497.4364 1608452.2108 APPROX POSITION XYZ *
  •    0.0000        0.0000        0.0000                  ANTENNA: DELTA H/E/N*
    
  • 1     1                                                WAVELENGTH FACT L1/2*
    
  • 8    C1    L1    D1    S1    C2    L2    D2    S2      # / TYPES OF OBSERV *
    
  • 2019 8 28 5 54 46.7040000 GPS TIME OF FIRST OBS *
  • 2019 8 28 5 58 40.6040000 GPS TIME OF LAST OBS *
  •                                                        END OF HEADER       *
    
  • 19 8 28 5 54 46.7040000 0 5G19G 6G 2G13G 5*
  • 23143238.376 3 -2712.202 25.000 *
  •                                            *
    
  • 23440293.888 -197.537 28.000 23440289.881 *
  •          3       -145.353          16.000  *
    
  • 23519994.368 1643.217 26.000 *
  •                                            *
    
  • 22843804.708 2827.546 31.000 *
  •                                            *
    
  • 22588429.718 1 -288.989 27.000 *
  •                                            *
    
  • 19 8 28 5 54 46.8040000 0 5G19G 6G 2G13G 5*
  • 23143289.758 3 -2712.022 25.000 *
  •                                            *
    
  • 23440297.640 -197.729 28.000 23440293.712 *
  •          3       -145.353          16.000  *
    
  • 23519963.229 1643.978 26.000 *
  •                                            *
    
  • 22843750.870 2828.501 31.000 *
  •                                            *
    
  • 22588435.238 -289.193 27.000 *
  •                                            *
    
  • 19 8 28 5 54 46.9040000 0 5G19G 6G 2G13G 5*
  • 23143341.398 3 -2713.285 24.000 *
  •                                            *
    
  • 23440301.422 -197.679 28.000 23440297.155 *
  •          3       -145.353          16.000  *
    
  • 23519931.693 1644.512 26.000 *
  •                                            *
    
  • 22843697.022 2826.942 31.000 *
  •                                            *
    
  • 22588440.001 -288.899 27.000 *
  •                                            *
    
  • 19 8 28 5 54 47.0040000 0 5G19G 6G 2G13G 5*
  • 23143393.161 3 -2711.438 24.000 *
  •                                            *
    
  • 23440305.167 -198.076 28.000 23440300.629 *
  •          3       -143.048          16.000  *
    
  • 23519899.969 1644.309 26.000 *
  •                                            *
    
  • 22843643.270 2828.049 31.000 *
  •                                            *
    
  • 22588445.572 -289.256 27.000*

Nop, it something that can tell us the state of the system, more here: https://docs.emlid.com/reach/common/reachview/settings/

Got this from the simple report button for 10hz

Simple system report

app version: 2.20.7-rs2-rc0-r0

'wifi_status, interface: wlan0':

- wifi_mode: ap

- access_point:

    band: bg

    channel: 1

    password: null

  ip: 192.168.42.1

  is_added: true

  is_connected: true

  mac_address: 6C:21:A2:92:9F:E4

  security: wpa-psk

  ssid: reachbase:39:68

  uuid: 660c7a1c-eefc-42e1-915d-20181a224769

base mode:

  base coordinates:

    accumulation: '2'

    antenna offset:

      east: '0'

      north: '0'

      up: '0'

    coordinates:

    - '0'

    - '0'

    - '0'

    format: llh

    mode: single-and-hold

  output:

    enabled: true

    format: rtcm3

    path: tcpsvr://:9000#rtcm3

    type: tcpsvr

  rtcm3 messages:

    '1006':

      enabled: true

      frequency: '0.1'

    '1074':

      enabled: true

      frequency: '1'

    '1084':

      enabled: true

      frequency: '1'

    '1094':

      enabled: false

      frequency: '1'

    '1124':

      enabled: false

      frequency: '1'

bluetooth:

  discoverable: false

  enabled: false

  pin: '***'

correction input:

  input2:

    enabled: false

    format: rtcm3

    path: ttyMFD2:38400:8:n:1:off

    send position to base: 'off'

    type: serial

  input3:

    enabled: false

    format: rtcm3

    path: :9028

    type: tcpsvr

logging:

  base:

    format: RTCM3

    started: false

    version: null

  correction:

    format: RTCM3

    started: true

    version: null

  interval: '24'

  overwrite: true

  raw:

    format: UBX

    started: true

    version: null

  solution:

    format: LLH

    started: false

    version: null

lora:

  air rate: 2.6000000000000001

  frequency: 868000

  output power: 20

position output:

  output1:

    enabled: false

    format: nmea

    path: bluetooth

    type: bluetooth

  output2:

    enabled: false

    format: llh

    path: :9001

    type: tcpsvr

  output3:

    enabled: true

    format: llh

    path: :2014

    type: tcpsvr

  output4:

    enabled: true

    format: llh_ext

    path: :2015

    type: tcpsvr

rtk settings:

  elevation mask angle: '15'

  glonass ar mode: 'off'

  gps ar mode: fix-and-hold

  max horizontal acceleration: '1'

  max vertical acceleration: '1'

  positioning mode: static

  positioning systems:

    compass: false

    galileo: false

    glonass: false

    gps: true

    qzss: false

  snr mask: '35'

  update rate: '10'

10 hz is indeed reflected in the simple report. But you wanted it at 1 hz, right ?

@wizprod Maybe @jjb means that not only does he want 1Hz output, but he also wants the output synchronized exactly at x.000 seconds. e.g. not 46.704, 46.804, … but 46.000, 47.000 …

Something tells me this might not be an easy thing to do…

But maybe the easy hack is just to modify the position output string by truncating the reported time down to the nearest second.

2 Likes

@bide yes, I need to record raw gps data at 1 second intervals synchronized at every 1.000000 seconds not 1.704xxx intervals.

In other GPS units you just set logging intervals at 1,5,10,etc intervals and the resulting RINEX files are recorded at exactly every 1.000000 seconds and not 1.7002 seconds.

Alrighty :smiley:
Well, yeah for that we need some help from @dmitriy.ershov and his team :smiley:, as it is feature request.

Hi Jun,

You can set up the update rate to 1 Hz in the RTK Settings ReachView tab.

May I ask you to clarify why do you need such intervals? Usually, PPP services and PPK software work fine with RINEX data from Reach.

Previous rinex files from other brands have rounded off time intervals - 1,5,10 seconds. First time I have encountered intervals with decimal values. I plan to use rs2 with Sokkia and topcon units via rinex files. I just received the rs2 and have not yet tested it with other units because they are still being used in the field.
Won’t this decimal time intervals affect post processing if other units have rinex time intervals rounded off to nearest seconds?
Thank you very much.

I can’t tell how it reacts with TopCon/Sokkia Rinex, but using CORS data from EUREF (that many times are from Leica gear) have not been a problem at all in RTKPost.

Obviously there will be a very small delay in correction, but there we are talking 10ths of a second, so in reality, nothing.

This shouldn’t be an issue

1 Like

Thank you for the feedback.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.