@cecomir88 If you have no coverage in your area, why are you gonna use NTRIP? Please post a screenshot of destination error.

@ilyavialkov
works now perfectly. thank you!

@ilyavialkov i'm working on a project for a european company that makes robots that cut grass, initially we use caster BKG as a base but faced some problems with its operation and lack of necessary support. And now we are looking for an alternative, if everything suits us, we will buy a license and cooperate.

I agree, I should communicated this transition better. But without shutting down the old system we could not move forward. There will be no breaking changes in the foreseeable future.

The next big step for YC will be a mobile app.

@josep-bello no plan so far

@berkayoral It's probably possible, but we will need to update our build script. It seems too niche to invest time.

@alduxvm said in Mountpoint configuration:

@ilya Thanks a lot of the video!

Yes, I have no problem with how to use it, the issue I think it might be my configuration, for example, when you used the reach antenna, how did the configuration looked on the mountpoints.yml?

First of all, mountpoints.yml is optional, caster will work completely fine without it.
Second, the description section in mountpoints.yml does not affect connection, its only purpose is to be a record in the source table.
Some receivers, when they act as an RTK base, send a source information in the NTRIP request header. It is look like this:

NTRIP-STR:5640425;CMRx;CMRx(1);2;GPS+GLONASS;;;18.01;-11.82;0;0;Trimble R10;none;B;N;9600;none

But with file based auth, aka mountpoints.yml, you can't get this string from the request.

If you want to use it, you will need http based auth.

@ilyavialkov do you know RTCM 3.2messages that LEICA read for fix?

@maxi012322 Hm.. Did not get such an error previously. Please publish your caster config file, I will try to replicate it.

@maliksarfrazahmed Sorry for late reply. We are using Linode data centers to run our NTRIP casters. Unfortunately there is no Linode data center in Qatar.

Today we updated how our casters handle base station source information. Previously it used data from source form (description) and ignored the data that got with the base station connection request.

Now it use this request data by default, and only if 'Override source' is enabled, it will use data from form.

For example:
Screenshot 2022-12-11 at 7.17.37 PM.png

In this case, the format will be xCMR no matter what is in the RTK base connection request.

In your case, just keep 'Override source' disabled. And the format will be set automatically.

Thanks a lot for your help!
Impatiently waiting as I need to switch to a different Caster than the well known... so if it's one that runs on Linux, even better! 🙂

@touritailglm This setup in general should work. I don’t think you'll get corrupt messages or something like this. But before send them you should set accurate antenna coordinates and switch your f9p to base station mode. You can't do this f9p setup with YCServer only.

Best regards, ilya

@ilyavialkov Initially, I asked about authorization through a file, but now I realized that this is not my way. Authorization via http is more flexible and solves the problem when scaling casters with a single database. So I started developing the back-end. Thanks anyway!

@ilyavialkov I removed authentication through a file, but that didn't solve the problem:

caster: host: yccaster-svil.sigemi.cloud address: 0.0.0.0:2101 identifier: My caster operator: My organization nmea: 1 country: EST latitude: 59.44 longitude: 24.74 fallback_host: 0.0.0.0 fallback_port: 0 misc: Some notes configuration: auth: - type: http options: url: http://127.0.0.1:8888/yc-caster-api/mountpoints/ntrip_auth secret: super_secret api: host: yccaster-svil.sigemi.cloud address: 0.0.0.0:8080 api-keys: - "104ebb67-a4bq-4c20-we36-99cb759d1ee9" events: - type: file options: path: /var/caster/session.log types: - caster-ready - caster-terminate - connection-accepted - connection-terminated - ntrip-request-accepted - ntrip-request-rejected - ntrip-session-started - ntrip-session-ended license-key: ""

and now in the logs there is no attempt to connect the source, only this:

{"name":"caster-ready","timestamp":1689165626,"data":{"address":"[::]:2101","started_at":1689165626}}

Sorry for the late reply, I will need to set up some kind of notifications :-). We replaced cloud source/destination with a free NTRIP caster that does not require authentication. So NTRIP source/destination can be used the same way as 'Cloud'.

@siradams No. It is not possible now and we have no plans to implement such functionality. Technically you can count the number of simultaneous connections on your side and just refuse a new connection if the limit is exceeded.

@alduxvm Hi
Yes, you will need a separate NTRIP server for your rpi. Something like str2str, but i don't know where to get it for Arm. Yccaster can't act like a server.

@touritailglm Yep. Only serial or bluetooth so far.

@carlomantega Are you talking about installation on your own server?

@ummagumma44 Hi
Please attach your clients.yml file, I'll check it