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.