Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - stevehayles

Pages: [1]
1
General Discussion / Air Quality Bricklet firmware 2.0.3
« on: February 05, 2019, 09:36:47 »
Just a heads up really, the recent commits in the generators repo includes a new call to remove the calibration for the air quality bricklet but the bricklet itself doesn't appear to have the corresponding function avaialable ?

Maybe this is normal and the bindings deal with it but I was studying the source code to work out how to write some custom firmware and thought I would flag it up

2
General Discussion / Updated .Net bindings
« on: January 29, 2019, 16:42:33 »
Hi,

Been working with the Tinkerforge system as a prototyping platform for a commercial product. Very well designed and easy system to work with but the .Net bindings are tied to some legacy framework versions and quite 'ugly' with the requirement for 'out' variables etc.

I have just released a new set of bindings with three big updates.

Firstly there is full support for ValueTuple returns on all functions with full property naming.  It allows calls like

Code: [Select]
var result = imu.GetAllData();
var accel = result.Acceleration;
var angles = result.EulerAngle;

rather than having to deal with multiple 'out' variables. 

There is also a fully async version of every call implemented using the Async/Await pattern.  The IPConnection class implements all socket send and receive calls asynchronously and there are async overrides of each available call.  The combined effect is that the above example can be written as

Code: [Select]
var resultAsync = await imu.GetAllDataAsync();
var accel = resultAsync.Acceleration;
var angles = resultAsync.EulerAngle;

This code is properly async and not just wrapping synchronous calls in Task.Run().

The last addition is the use of Reactive.Linq and a full set of extension methods to allow the use of IObservable on every brick or bricklet callback.  RX Extensions allow a composable and functional approach to streams of data.

Time shifting of sequences, buffering, throttling and all sorts of manipulations become very easy with a Linq based approach.  The underlying callback event is converted to an IObservable and the disposal of event handlers is all handled automatically.

The example below subscribes to a stream of data coming from the imu but it's 'throttled' to only produce data every 500 milliseconds regardless of the incoming rate from the brick.

Code: [Select]
imu.WhenOrientation()
    .Sample(TimeSpan.FromMilliseconds(500))
    .Subscribe(async v =>
    {
        Console.WriteLine($"Heading: {v.Heading}");
        await Log.WriteAsync($"Roll: {v.Roll}");
    });

The nuget package is available at https://www.nuget.org/packages/FiftyOneNorth.Tinkerforge/ (FiftyOneNorth.Tinkerforge)

The complete set of bricks and bricklets are covered and I will try and maintain compatibility with future releases.  Keen to hear other's experiences and hope it's useful to someone

Thanks,

Steve Hayles
Fifty One North Ltd

3
General Discussion / IO-4 Bricklet 2.0 Interrupts
« on: July 21, 2018, 14:57:54 »
Hi,

In the version 2.0 of the IO-4 bricklet we have lost the ability to have an interrupt from any of the inputs. 

This is viewed as an 'improved' API but it seems that simple interrupts can be very useful in a number of scenarios.  I was using the older IO-4 bricklet to interface with a low frequency flow meter and it's hard to replicate a similar system now with the new bricklet.

Will the original bricklet be discontinued at some point ?

Is there any way of adding interrupt capability to the new bricklet ?

Will the IO-16 board go the same way ?

Thanks

4
General Discussion / IMU brick improvements needed
« on: July 20, 2018, 12:09:37 »
Hi,

One for the developers and hopefully not a difficult change.  The IMU v2 based on the Bosch BNO055 which has more 'sensor fusion modes' than we have options for.

In testing the unit I have found that the FMC (fast magnetometer calibration) is troublesome and makes yaw / compass / heading output very unrepeatable.

There is a fusion mode called 'NDOF_FMC_OFF' (0b00001011) which is the same as the BrickIMUV2.SENSOR_FUSION_ON mode but has the auto calibration routine for the magnetometer disabled.

You can still store a full calibration profile and all other functions are the same.  Using the same chip in an Arduino device has resulted in a more stable system without the unexplained 'jumps' in yaw output that are often seen in the NDOF mode

It looks like a simple enough change with no backward compatibility issues ?

Thanks for your consideration

5
General Discussion / Improved C# bindings
« on: February 28, 2018, 15:32:35 »
Hi,

I'm yet to actually receive any Tinkerforge products but I am evaluating it as a prototyping platform for a commercial product.  The multiple language bindings are fantastic but we do a lot of work in CSharp and this will be our primary language.

The legacy support for .Net2 is understandable but prevents the use of a number of new language features.  In our test code the biggest single issue was the use of the 'out' style return values.  It felt like a 'code smell' from day one and more importantly is a major hurdle to placing these calls inside Async / Await style methods. 

To this end I have just finished a T4 template solution that takes the existing bindings and wraps every appropriate call (that has an out parameter) in an extension method that allows the use of a named tuple return type. 

This will maintain complete backward compatibility but allow some much cleaner patterns for users of newer .Net frameworks.

As an example the original call in the 'BrickletRGBLED' class remains

Code: [Select]
public void GetRGBValue(out byte r, out byte g, out byte b)
{
byte[] request = CreateRequestPacket(8,FUNCTION_GET_RGB_VALUE);

byte[] response = SendRequest(request);

r = LEConverter.ByteFrom(8, response);
g = LEConverter.ByteFrom(9, response);
        b = LEConverter.ByteFrom(10, response);
}

but a new file is created called 'BrickletRGBLEDExtension'

which contains

Code: [Select]
public static (byte R, byte G, byte B) GetRGBValueEx(this BrickletRGBLED device)
{
        device.GetRGBValue(out byte r, out byte g, out byte b);

return(r, g, b);
}

This allows a very simple call like

Code: [Select]
        var result = brick.GetRGBValueEx();
        var red = result.R;

        //or

        var red = brick.GetRGBValueEx().R;

It requires VS2017 and .Net 45 or later but without that requirement the problem does not exist in the first place.

I am keen to release these to the community and wondering if it's best as a Nuget package library or to release the actual templates so that issues of keeping the packages in sync don't cause issues.

The templates might need small tweaks for users local environment but they run very quickly and produce a complete set of extensions for every device.

Keen to hear peoples thoughts

Pages: [1]