Hi Simon
It should work fine with CMRx. Protocol is not important.

@josep-bello no plan so far

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

@kalibaru-survey Hi
You can cancel your subscription on Plans & Billing page. Click details menu on current subscription item.
Screenshot 2024-05-16 at 6.34.00 AM.png

Hi @neshmi, thank you for your message.
Currently we do not store usernames or mount point names in caster. But each connection has a unique connection_id. This connection_id is present in all events and auth requests. So you can match events with a particular username by it.

nope, we don't have

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

Hi @lodbrokjason
Not at the moment, we kinda soft launched the app for android. But then we get a bunch of ideas about team management. So now, we are working on API and web app, then updating app for android. and then ios app.

Too many ideas to little menpower.

@owsleyssalvation Yep, sometimes live is frustrating.
As I understand, you want to broadcast RTK corrections from you base to your drone. Please, describe your setup. Drone, base station, and so on

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! 🙂

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

@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}}

@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!

@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 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.