Sorry for the delay here... The question is actually more tricky then it sounds.

I start with question 2 as the answer might affect the rest:

2. We generally don't log in Rinex directly (so *.rnx) - Trimble uses a binary T0X format (where X is essentially something like a version number). Most modern receivers allow to transform via the WebUI from T0X to Rinex on the fly - so while downloading the file. But I'm not aware of any SDK/ API that exposes this. So the default workflow for data logging would be to start a data logging session (static or fast static) on the receiver, then download the T0X file, then process the file either via a T0-to-Rinex converter or something that understand T0.

The file gets typically collected and stored on the receiver first - as you would otherwise need a permanent, ultra stable and fast Bluetooth connection.

1. We do have SDKs suited for Android - one of them being Trimble Precision SDK for Catalyst.

Technically the interfaces available in the Catalyst SDK expose data logging (so starting and ending a session on a receiver) - but as the SDK currently focus on Catalyst there is no device which actually implements the data logging interfaces.

We plan to update the current Catalyst SDK soon - this update adds traditional receiver support which do implement the data logging interfaces. But I can't give you a time frame on this. But we also want to have this from our plate to have a consistent solution for Android.

The SDKs gives you generally the possibility to connect and control a receiver (either a SoftGNSS receiver or a physical one); IF the receiver supports data logging the corresponding interfaces will be available.

So the way TPSDK generally works is that you check if an interface is instance-able; if its not null (when you ask for it) it means the receiver supports it and you can use it.

You could start with the exsting release of TPSDK for Catalyst and look at the Facade implementation (so where the low level stuff is used) - but you can't test it right now as we have no driver supporting it in the current release.

BUT - now the next hook. You mentioned you plan to use Ionic. The SDK is currently available in Java or Xamarin. You would need a method to bridge from Ionic JavaScript/ HTML5 down to Java/ a Java Android service/ something like this.

So even if the SDK is in place its not straight forward.

I stop here as this is already quite a bit of information. If you don't need data logging but just a 'good position' it would make things simpler. But thats potentically a topic for a second comment.

Thanks for the response Nico. The ultimate goal of this project is to simply get an accurate (sub-foot) location, using Ionic on an iPhone (through the R2). We don't actually need the GPS logs, we were hoping to get them to do manually post-processing corrections in remote locations (when the automatic correction service was not available). We do not want to have to depend on any other Trimble-specific applications (like GNSS Status). Any advice or direction on this goal?

So we don't have an official protocol definition for the RSeries receivers. For this purpose - so that no one has to mess with the binary protocol - we provide the SDK(s). Which do not solve all problems as seen here.

The best tools available on Android are currently either the TPSDK for Catalyst or the SDK that sits below GNSS Status (so there is also an interface here called GNSS Direct). But the second one is more limited then the first - and stuff like data logging is completely out of scope for that one. On the other side it exists for both Android and iOS.

I'm also not sure how the ionic Bluetooth stuff (didn't know that low level coms do work now on those cross platform HTML5ish tools - good to know) works in conjunction with iOS. In order to get a serial profile up and running on iOS you need to run through the MFi registration - at least for the sort of devices Trimble produces. So I'm not sure if this will work at all with direct communication.

I guess the best/ only thing you can do if iOS is in the game next to Android is to go for GNSS Direct. If you like I can get you in contact with the people responsible here. Otherwise it will be Android only for some time.

In all cases you have some sort of dependencies/ libs you link - so we can't go without them.

Plan C is to use simple NMEA - but this limits your workflow/ scope potentially.