JavaLaurence

Hi,

I'm considering a project whereby I'd need a matrix of buttons *like* the TF "RGB LED Button"s.. but without the steep components cost involved since I would need a matrix of at least 8 x 8 (64 buttons), or much better 10 x 10 buttons. Does anyone here have some idea on how to build something like this really cheap? I.e. a matrix whereby each button's RGB LED is controllable, and each button produces its own unique on/off event? (For those with synthesizer knowledge, I'd like to obtain something resembling the matrix in the Arturia MatrixBrute synth).

Thx for any ideas/pointers.

Thanks for the clarification. I then have a second question: can the addition of a co-processor and more robust connectors be done without changing the price levels that TF users have grown accustomed to?

It looks to me as if this co-processor will need to be really, really cheap for it not to have an end-user price impact..

I seriously frowned when I read these words: "in a three year time frame."

Three years sounds unrealistically long. Three years is an eternity in politics and in technology. Such a strategy implies that you impose upon your customers a transition period that is that long. I think 3 years is huge, and a completely wrong period for the kind of products we're talking about, and the kind of company you are. To be frank, it's just plain weird. If, as an alternative, you said "By the end of 2017 we'll have all bricklets converted to the new design".. I for one would be happy to continue thinking of Tinkerforge as a viable ecosystem for current and future projects. But three years? Sorry.. not me.

I'll also add that I question why such a massive earthquake is needed? You mentioned the event counter use case.. that's one use case. Have you been inundated by other use case requests from customers that justifies such a major undertaking? What about all your existing customers who are perfectly happy with the current approach, including the fragile connectors? Your proposal means complete backwards and forwards incompatibility. I currently can't see the crystal clear business case for putting yourselves and us (customers) through such a huge change.

My 2 cents..

On the English home page, when you click on the left section announcing the new Wifi extension, your English-speaking/reading customers land on the German Wifi extension page. (still the case today, just checked)

FYI, the text for the new Wifi extension has been stuck on German for days... on the English side/site.

This could be interesting for very young people.. though I'm having trouble seeing which age group can both master the concepts of variables, hosts/ports, and require the extreme vulgarisation of a totally Lego-block style language.

My guess is that any youngster who has tasted any conventional text-based programming will not wish to invest any time in this.. (just guessing).

Hi TF fans,

Just sharing my latest little project. The venerable Pong video game, "TF" style, using the latest OLED displays.

The main display is really tiny for this kind of application, but it's fun to play nevertheless. 

PS. For social media followers, I've also tweeted about this using the #tinkerforge hash.

Thanks for the explanation. Given the technical limitations, the current API does indeed make more sense. But if you do have half a K of spare flash, I think adding the plot(), fill() and clear() APIs would be very simple for you to add... and it would give people a way to avoid the complexity of an intermediate render on the host, as shown in your examples.

If I may express my opinion on this, I think Tinkerforge should be given a medal for supporting a broad variety of programming languages, and in so doing help people with possibly very little programming experience so far.

But it is exactly in this beginner-friendly approach that ultra low-level APIs don't fit. Experienced programmers can deal with APIs that expose little more than what the hardware natively exposes.. but that's a tough learning curve for a beginner.

Having to implement Bresenham's line drawing algorithm to obtain a drawLine(x,y, x,y) API is in my opinion not compatible with the whole rapid "tinker" philosophy.

I just checked the API, expecting to find a plot(x,y) as an absolute minimum, but couldn't find this.

To be honest, I think the following would be really appreciated by lots of people:

- plot(x,y)

- fillRect(x,y,w,h)

- clearRect(x,y,w,h)

- line(x1,y1, x2,y2)

Could Tinkerforge team please indicate whether these will be added at a later date, or should we tackle this ourselves?

Thanks!

  Laurence

/var/log/brickd.log is empty.

How do I find out which version is running? Can't the viewer give me this information?

Thx.

  Laurence

Hi TF team,

Would it be possible if you enhanced the API for the Segment Display bricklet so that we can

a) put any integer in the range 0..9999 on the display in a single call (without having to mess with the segments individually)

b) put any single-digit decimal in any of the 4 available slots, again, in a single call.

Given that you must already have the code to control the segments to "render" digits (hidden within your counter API), I would imagine that adding the above is very little work.

Thx!

  Laurence

I ordered the sensor with the purpose of seeing if traffic pollution can be detected. I don't actually care how the pollution is classed (PMxxx whatever). I'm only interested in seeing a change in value when the traffic is known to be sending us polluted air in our direction.

Will report back here once I've been able to test the sensor (waiting on delivery).

  JL

I would very much like the answers to the same questions. If the answer is yes, then I'm buying the sensor, otherwise not.

Thx for reply. Just a data point: in Belgium a major carrier is deploying a nationwide LoRa network, marketing towards IoT applications.

Are there any plans to add LoRa compatibility to the TF ecosystem?

So your generator is written in Python? If so, then I think we've got a language barrier blocking any merging of efforts.. Long live the Babel tower of languages (somewhere I read there's even a programming language that has to be typed in Arabic.. it clearly is never going to stop).

@Theo: I'll describe what I've done..

First of all, I wanted all concrete TF classes for bricklets to become interfaces. Chiefly so that I could have multiple implementations (e.g. one bound to the real hardware, another bound to an emulated bricklet, a unit test mock, etc.)

To obtain those interfaces, I wrote a code generator that parses the official TF JAR, and generates the interfaces, and a bunch of other things (like concrete classes wrapping the TF bricklet classes, and implementing the interfaces).

I also wrote a few (not many) emulated bricklets. E.g. the LCD bricklet, various sensors.

The end result is that I can write TF applications that are interface-based, and which can trivially switch execution between emulated and real hardware.

By the way, it's kind of ironic that my approach is code generation-based, because Tinkerforge also uses a code generator as their foundation for language-neutral description of all their devices.

@kinfkong: which language do you intend to work with? If Java, I may have some simulator-esque material which may be useful to you.

Hi,

Looks like the available Load cell weighing range tops out at 50kg. Unfortunately, most adults weights lie within 50-100kg, so are there any plans to offer 100kg max weight Load cells?

Thx.

Hi,

The new Accelerometer mentions in its documentation:

"Full 1kHz data rate with callbacks"

Can we get the same info for the Laser Range Finder?

My Use Case for the range finder is detecting fast-moving objects, and I'm wondering what the sampling rate is. If the rate is too low, my idea won't work..

Thx

Any information on why the new bricklets aren't yet for sale?

If I recall correctly, the LED bricklet is limited to controlling an upper limit number of LEDs, depending on how much RAM the Brick has available. In other words, what else do you have connected to the Brick to which you've added the LED Bricklet? Try removing all other bricklets..

Ironic that some of us are making hardware robots, while others are making software bots to spam the world...

The whistle attributes (pitch, volume) didn't seem to correlate with any loading of the LEDs. But after about 20 minutes the whistle faded away. My project has been running 24/24 for nearly a week now, and the whistle hasn't returned. So maybe the PSU simply needs to warm up a bit?