Magic Leap One No device is connected

When developing apps for Magic Leap One, we can use the Magic Leap Remote app to start the device connectivity and deploy our apps directly from the Unity Editor. Even when the ML1 device has been configured for development purpose by enabling the creator mode, installing the certificate and allowing MLDB access, there may be a “No Device is Connected” error. In this article, we take a look at how to use the MLDB CLI to address device connectivity problems on a Windows computer.

What is MLDB?

The Magic Leap Device Bridge (MLDB) CLI is used to provide direct connectivity to the device via USB and WIFI.  We can also use this CLI to directly deploy apps onto the device. It is during the deployment process when we can notice connectivity problems with our computers.

Is the device connected?

Assuming the ML1 device has been configured properly for MLDB connectivity and that we have a verified USB connection, we are going to start to troubleshoot the connection error by starting the MLDB CLI and typing the following commands after the > prompt:

>mldb devices --output List of devices attached

If we get no device serial number on the output then we know that we have a problem with the device connecting to our PC via USB. To double check, let’s take a look at our Device Manager panel and check the Universal Serial Bus Devices configuration.  If we find our ML1 listed there (see image below), we know that the physical connection via USB is working. 

Let’s Repair our Registry Settings

We know that a physical connection is working, but we still do not see the device via MLDB CLI. We need to check that our device registration in our PC as USB connection is valid by using the CLI and checking our registry settings with the following command at the > prompt:

>mldb usbreg Found connected ML device with serial number: ### GOOD: Device has a container node. GOOD: Device has an interface GUID for the non-composite device. BAD: Device is missing an interface GUID for the first composite interface BAD: Device is missing an interface GUID for the second composite interface Created registry file that should fix the issue: \mlsdk\v0.20.0\tools\mldb\mldb-fix.reg Double click the file in Windows Explorer to update your registry, then unplug and replug your ML device. MLDB should now recognize the device.

We should now see some messages indicating if there are any problems. If any problem is found, a new registry setting file is created, and we need to import it into our system. But before we import the file, we can take a look at our registry settings and compare it to the values in the newly created file.  This can allow us to understand what is going on.

We can open the new registry file to learn the path for our registry. We can then type regedit command on the CLI to open the registry database in our computer. By comparing the file with the values in our registry, we can see that the DeviceInterfaceGUID on our registry is no longer matching what our device is reporting. This make sense, so we need to update our GUID value with the one provided by the output of the mldb usbreg command.

Conclusion

After updating our registry settings and reconnecting our device via the USB port, we should be able to run the mldb devices command again and see our device listed on the output. If we restart the Magic Leap Remote app and press the Start Device button, we should see that our device connects and it is ready for us to deploy our apps via the Unity editor or the MLDB CLI.

I hope this provides some insight on how to address the No Device is Connected error when using the Magic Leap Remote app.

Thanks for reading

Originally published by ozkary.com

When developing apps for Magic Leap One, we can use the Magic Leap Remote app to start the device connectivity and deploy our apps directl...

Read Article →

Omit Data Members with JavaScript and CSharp

When calling Restful APIs with a well define JSON contract, we get errors on the request when we submit a JSON payload that does not meet the contract specification.  In many cases, we use a model that may have properties which we need to ignore from the payload before submitting to the API. In this article, we take a look at how a data member can be omitted to maintain the JSON contract definition using both JavaScript on the device side and C# for our backend services.

Defining Our Contract

For the context of this article, we are working on a telemetry API with the following JSON contract which only captures the device id and telemetry information like temperature, humidity and sound levels.

Telemetry { deviceId (integer, optional), temperature (number, optional), humidity (number, optional), sound (number, optional) }

Omit a Data Member in JavaScript

From the device side, we are capturing the information with JavaScript.  There many other data points that we capture on the device, but we only want to send the properties listed on the JSON contract. There are several approaches to rebuild the model and capture the properties that we need. On this article, we will take a look at the approach of cloning the contract and mapping properties to a new object.  Let’s take a look at our solution using JavaScript.

var device = {     "deviceId": 2026,     "humidity": 65,     "location": "stock-23450",     "sn": "br52552endn",     "sound": 120,     "bu": "mfr2939",     "ver": "3.4.0",     "robot": "rb5625",     "temperature": 35, }; var contract = {     "deviceId": 0,     "temperature": 0,     "humidity": 0,     "sound": 0, } function cloneAndMap(device, contract) {     var data = null;     if (device) {         var data = Object.assign({}, contract);         for (var key in data) {             data[key] = device[key];         }     }     return data; } var data = cloneAndMap(device, contract);

As shown in the code, the device object has several more properties that are not relevant to our API. We want to be able to get only the properties that are defined on our contract object.  A way to do this is to clone the contract object using Object.assign native API to shallow copy the object. We then read every key from our contract object and use those keys to get the values from our device object. The main logic is handled by the cloneAndMap function.

We should note that objects in JavaScript are dynamic data types that are essentially hash tables. This enables us to have constant time ( time complexity O(1) – one operation to access the data ) access to the hash table values by using the key for each field. This works out well for us because the device data can have hundreds of fields, but we will access each field in constant time. We are only bound to the contract object size which is much smaller and well define to n=4 fields, so the time complexity to traverse all the contract keys is O(4).

We should also note that we are cloning the contract object because we want to continue to reuse it for other API calls. We also decided not to clone the device object because its running time T(n)  would depend on the size (n) of all its properties which is much larger than the contract. We would then need to delete the unwanted properties, but we know that objects in JavaScript are immutable. This means that every time we delete a property a new object will be created. This is a performance concern.

Ignore a Data Member with Attributes C#

Now that we understand how to ignore a data attribute with JavaScript, let’s take a look at how that can be done using C# by first looking at our model definition.

/// <summary> /// device telemetry readings /// </summary> public class Telemetry {     /// <summary>     /// device id     /// </summary>     [DataMember]     public int deviceId;     /// <summary>     /// internal id     /// </summary>             [IgnoreDataMember]     public long Id;     /// <summary>     /// temperature reading     /// </summary>     [DataMember]     public float Temperature;     /// <summary>     /// humidity reading     /// </summary>     [DataMember]     public float Humidity;     /// <summary>     /// noise/sound reading     /// </summary>     [DataMember]     public float Sound;      }

We define our telemetry class with the same attributes as our JSON model. There is however an internal Id data member which we may use for internal purposes, but we do not want to serialize as JSON to the client application. When we want to ignore a property on C#, we can use the IgnoreDataMember attribute which is in the Serialization namespace and declaratively ignore the property.

This IgnoreDataMember  attribute enables us to change the default behavior of the DataContractSerializer which by default serializes all public properties. In our case, we still want to maintain the Id property with public accessibility, so it is available to other backend integrations that are not in the same assembly.

We should note that by setting the Id property to internal or private also prevents the serialization of the property to JSON. This however impacts accessibility to the data member. We need to look at our system requirements and determine the best approach as those other access modifiers prevent the accessibility of that property to other assemblies and classes.

Conclusion

With this article, we are able to see how to omit additional properties in the application model, so we can maintain our JSON contract using both JavaScript for the client app and C# for the backend API. We looked at how depending on the implementation approach we can optimize the solution for time complexity and accessibility concerns.

Thanks for reading.

Originally published by ozkary.com

When calling Restful APIs with a well define JSON contract, we get errors on the request when we submit a JSON payload that does not meet t...

Read Article →