Messages

1

General Discussion / Re: Updated .Net bindings

« on: February 09, 2019, 14:01:37 »

Updated to version 1.0.3 with following improvements

Air quality bricklet - Add API for changing background calibration duration

2

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

3

General Discussion / Re: Updated .Net bindings

« on: February 04, 2019, 21:47:56 »

Updated to version 1.0.2 with following improvements

Improved callback/continuous callback documentation

Add RemoveCalibration function to Air Quality Bricklet API

4

General Discussion / Re: Updated .Net bindings

« on: January 30, 2019, 11:57:10 »

Great move to go to .Net Core, it's the future !

My bindings work very well in a .Net Core environment and I am currently running them on a Raspberry PI to great effect.  I have a custom RPI image running with the .Net Core run-time built in and my next move was to look at the Red Brick and try and do the same there but if you are considering it then I am sure you will do a better job.



 

5

General Discussion / Re: Updated .Net bindings

« on: January 30, 2019, 11:28:35 »

Hi,

I don't want to 'pollute' your bindings in any way and at present my library is built as a combination of a modified "generate_csharp_bindings.py" python script and then a T4 template to generate all the extension methods.

This could all be done entirely within the current python framework but it's a much bigger change.  Maybe a completely separate "generate_csharp_bindings_V2.py" script with the original untouched would be the way to go ?

6

Projektvorstellungen und Projektideen / Re: C# API Plus

« on: January 29, 2019, 18:04:20 »

Hi,

Not sure if this package is being maintained.  Please see https://www.tinkerunity.org/forum/index.php/topic,4748.0.html for another option with Async/Await support and other additional features

7

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

8

General Discussion / Re: IO-4 Bricklet 2.0 Interrupts

« on: July 26, 2018, 08:36:07 »

Thanks for your reply, it makes sense now.  I was looking for a way to get an interrupt on a single edge (rising for instance) and with that in mind I misread the documentation.

I guess the simple answer for now is to simply filter out the 'falling edges' in my own code.  This will work fine for now although maybe long term being able to configure these callbacks for which edge type would be a nice addition.

Loving the Tinkerforge system by the way !

9

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

10

General Discussion / Re: IMU brick improvements needed

« on: July 21, 2018, 14:27:24 »

Hi,

Tested and working here.  Thank you for the amazingly fast response.

The BNO055 has some quirks around the magnetometer and compass / absolute yaw output.  My testing has shown the mode to be useful.

Thanks again

11

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

12

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