Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Google around and you will find countless issues with the Bosch BNO055 and it's auto calibration routines especially around 'heading' or yaw. I tried absolutely everything and the Tinkerforge guys were great with a small change in the firmware that allowed a different mode to be enabled but I was never successful in getting a reliable and consistent heading. I gave up and went for a separate IMU but still integrated with the rest of the boards from Tinkerforge
  2. Updated to version 1.0.7 with following improvements Added Compass Bricklet Added Energy Monitor Bricklet Added XMC1400 Breakout Bricklet Added Distance US Bricklet 2.0 Added Color Bricklet 2.0 Added Rotary Poti Bricklet 2.0 Added Multi Touch Bricklet 2.0 https://www.nuget.org/packages/FiftyOneNorth.Tinkerforge/1.0.7
  3. Updated to version 1.0.6 with following improvements Added Laser Range Finder Bricklet 2.0 Added Hall Effect Bricklet 2.0 Added Segment Display 4x7 Bricklet 2.0 Added E-Paper 296x128 Bricklet Added Laser Range Finder Bricklet 2.0 Added Piezo Speaker 2.0 Added Linear Poti Bricklet 2.0 Added Joystick Bricklet 2.0 Added RGB LED Bricklet 2.0 https://www.nuget.org/packages/FiftyOneNorth.Tinkerforge/1.0.6
  4. Updated to version 1.0.3 with following improvements Air quality bricklet - Add API for changing background calibration duration
  5. 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
  6. Updated to version 1.0.2 with following improvements Improved callback/continuous callback documentation Add RemoveCalibration function to Air Quality Bricklet API
  7. 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.
  8. 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 ?
  9. 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
  10. 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 var result = imu.GetAllData(); var accel = result.Acceleration; var angles = result.EulerAngle; rather than having to deal
  11. 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 !
  12. 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
  13. 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
  14. 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.
  15. 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
  • Create New...