JavaLaurence

Without the API, you need to jump through a few hoops to manage the segments yourself.. package com.softwarepearls.apps.hardware.tinkerforge.clock.sevensegment; import static com.softwarepearls.lego.hardware.tinkerforge.enums.BrickletType.BRICKLET_SEGMENT_DISPLAY_4x7; import com.softwarepearls.lego.graphics.SevenSegmentDigits; import com.softwarepearls.lego.hardware.tinkerforge.interfaces.io.SegmentDisplay4x7; import com.softwarepearls.lego.hardware.tinkerforge.stack.BrickletDescriptor; import com.softwarepearls.lego.hardware.tinkerforge.stack.TinkerForgeStack; import com.softwarepearls.lego.time.Frequency; import com.softwarepearls.lego.time.TimeAndDateKit; import com.tinkerforge.TinkerforgeException; import java.io.IOException; import java.text.DateFormat; import java.text.SimpleDateFormat; import java.util.Arrays; import java.util.Date; import java.util.List; /** * Bare-bones 24 hour HH:MM clock rendered on a Tinkerforge 7-segment display. */ public final class Clock { private static final int NUM_DIGITS = 4; private static final String DISPLAY_UID = "kTz"; private static final String TO_TF_SEGMENTS_LUT = "AFBGECD"; private final static DateFormat DATE_FORMATTER = new SimpleDateFormat("HHmm"); private static final List<BrickletDescriptor> EXPECTED_BRICKLETS = Arrays.asList( // new BrickletDescriptor(BRICKLET_SEGMENT_DISPLAY_4x7, DISPLAY_UID)); private static void go() throws TinkerforgeException, IOException { final TinkerForgeStack tinkerForgeStack = TinkerForgeStack.initializeTinkerForgeStack(EXPECTED_BRICKLETS); final SegmentDisplay4x7 display = (SegmentDisplay4x7) tinkerForgeStack.getBricklet(DISPLAY_UID); final Frequency clockRefreshFrequency = Frequency.EVERY_SECOND; while (true) { final int hhmmDigits = timeDigitsFor(new Date()); final short[] segments = getSegmentBitsFor(hhmmDigits); final boolean flashingColon = (TimeAndDateKit.currentSecond() & 1) == 0; display.setSegments(segments, (short) 2, flashingColon); clockRefreshFrequency.delay(); } } private static int timeDigitsFor(final Date time) { final String timeString = DATE_FORMATTER.format(time); return Integer.parseInt(timeString); } private static short[] getSegmentBitsFor(final int value) { if ((value < 0) || (value > 9999)) { throw new IllegalArgumentException("Illegal value for 7-segment display: " + value); } final short[] segments = new short[NUM_DIGITS]; int dddd = value; for (int i = 0; i < NUM_DIGITS; i++) { segments[NUM_DIGITS - 1 - i] = segmentBitsForDigit(dddd); dddd = dddd / 10; } return segments; } private static short segmentBitsForDigit(final int d) { final int digit = d % 10; final String litSegments = SevenSegmentDigits.DIGIT_DEFINITIONS[digit]; short segmentBits = 0x00; for (int i = 0; i < litSegments.length(); i++) { final char ch = litSegments.charAt(i); final int bitNumber = TO_TF_SEGMENTS_LUT.charAt(ch - 'A') - 'A'; segmentBits |= 1 << bitNumber; } return segmentBits; } public static void main(final String[] args) throws TinkerforgeException, IOException { go(); } }

void setCounterValue(short value); // value 0..9999 Would be really nice. Any plans on adding this? (just trying to make a simple little clock)

Hi TF team, I'm wondering if there are future API possibilities for the PiezoSpeaker that could be looked at? Is it physically possible to affect volume? Would it be possible to alter the waveform? The specs of the component talks about different driving waveforms. The spec also talks about voice synthesis... It would be nice if the API gave us a few more (musical) possibilities. I'm already getting some nice sounds from 2 detuned speakers. If the API could be enhanced, I would buy a few more to explore the sound-generating possibilities even further.

Yep, pretty cool software. In fact, I know of a few companies who would have paid a fortune for such capacity just 10 years ago. It is amazing what features can be found in free software these days. But briefly returning to the car counting problem. Did you notice how the video analysis URL you posted also did not latch on to the big white truck? So even if you have heavy-duty hardware and software, 100% is just an impossibility. Even putting a human next to a road, and telling him/her to count everything that passes for x hours... you're not going to get 100% accuracy. Google proved this point again with their house numbers recognition efforts: even humans as detectors don't give you perfection.

100% correct identification is always impossible with all low-level sensor approaches. The classic black hose over the road approach also does not count cars perfectly: if you have some kids dancing on the tube, their dancing will trip the detector. A light barrier could be fooled equally easily. Would it count passing pedestrians? Yes, if the beam is horizontal and low enough. So the beam would have to point downwards, so that it goes over the heads of pedestrians..? That approach would have other undesirable side-effects. And so on.. AFAIMK, 100% detection rate is always impossible, so I'm quite happy with a rate in the 95%+.

A few weeks ago I had the idea to count the cars passing in our street using some TF magic. Initially I thought maybe one of the Distance IR/US would work, but quickly realised that the cars would be out of reach of the detection range. Then I thought, "Sound Intensity" ? A passing vehicle produces neat peaks of noisy sound, and this ought to be enough to create some counting application. A couple of days of software tinkering, and it works ! Screenshot attached. It's far from perfect: a passing tractor was counted as 3 vehicles, and the occasional car that glides past really silently doesn't register at all. But so far, out of the 50 counts I'd say that 47 are real. PS. I bought 2x Sound Intensity, because I was hoping to extract vehicle speed too... that's next.

I think it's quite confusing to see those low numbers when, if you don't know the internals, you'd expect a TF stack to be able to communicate at much higher bandwidth. If you hear of any device that connects via USB or Wifi to a PC, then you kind of expect that device to be able to use "the most" of those transports. It's just an expectation/surprise thing...

Thx for the USB Spec ref (checked it.. very interesting). Apart from the source code (which I'd rather not have to consult), is there any technical documentation of how Tinkerforge uses USB ? Or rather, is there any docs on the entire comms architecture (USB and Wifi)? Sorry for being so nosy..

Thx for that reminder.. that's such a low rate.. :'(

Can anyone briefly explain why the Tinkerforge architecture limits its USB bandwidth to 1000 64-byte messages per second?

Hi, Quick the Easter discount clock is ticking. I would like to try and detect and measure cars driving past in our street by using two Sound Intensity Bricklets to get some kind of "stereo" waveform each time a car passes. Analysing those waveforms should allow me to deduce speed. To get this to work, I'll need a reasonable sampling rate. So Q: What's the fastest sampling rate for this Bricklet? Actually, wouldn't it be nice if each bricklet had an API that can tell a program what its maximum sampling rate can be ? Thx.

I read somewhere that RED Brick users will not need to be Linux nerds, and therefore a more user-friendly mechanism will be available to download programs into the RED Brick. In the case of Java support, may I ask what version of Java will be supported, and which JVM implementation will be used? These days, the Java world is on fire with the recently released Java 8... it would be pretty awesome if RED Bricks could run this uber-Java...

Hi, The blog mentions "an additional comprehensive protective circuitry" for the 1.2 hardware. I just had a peek at the schematic, but it still shows the 1.1 hardware. Is it possible to have a look at the new circuitry? (I abandoned my Tinkerforge project due to (old) Dual Relay issues, and I hope I may revive it with the new Bricklet..). Thx. Laurence

Distance IR is functioning perfectly. Everything works when assembled on my desk. The only real difference with the cellar config is that @ my desk, I'm powering via USB, not via Step Down. One more test coming up..

I've just added the Dual Relay to the stack.. but still without the Distance IR, and the stack works fine. So now only the Distance IR is left as culprit. Unfortunately, in my setup, that Bricklet is siliconed in place to guarantee stable orientation.. so will take it apart tomorrow and see.

My stack is a dual-Master Brick affair with a bit more than just Dual Relay and Distance IR. Anyway, I reassembled the stack without Dual Relay and Distance IR, and hooked it up to my Mac, and everything is OK... so the most likely cause is the Dual Relay having died. This immediately brings up the question: is it reasonable that enumeration fails completely because of a single bricklet being dead for whatever reason? I think enumeration should be more robust.. it shouldn't be the SPOF.

Hi chaps, After months of essentially trouble-free running, my control program now consistently fails to enumerate my stack's configuration. The Wifi extension seems to work OK (associates with router).. but the rest of the stack appears dead. Could this be a dead Master ? I've been running the stack on a timer switch for several weeks now.. switching the stack's power off for 30 mins every 2 hours. So you could say I'm cycling the components quite a bit...

The following stepper demo seems to show silent running .. I was just wondering whether I could get the same low dB out of a TinkerForge setup? If so, then I'll plunge in.. ;-)

Hi, Does the Stepper Brick allow virtually silent operation of stepper motors? I'm a stepper newbie so have never played with them, but I read that if the motor can be driven with a sine and cosine waveform, that silent operation can be achieved... I've got an idea for a project with stepper motors, but I need the motors to be silent.. Thx.

I meant in the same stack?

Can the Wifi and Ethernet extensions be combined in any interesting ways, or are they mutually exclusive?

Is the divide by 100 the problem? What does it produce if you don't divide at all?

AuronX: for the LCD, I have a reasonably authentic-looking emulation, including the programmable characters and buttons. Also, I beefed up the LCD API to be a bit more high-level than TF's (see attached interface definition). For the LCD API, I want to beef it up even further to allow the display of a 20-sample bar chart (using the custom chars). LCDCharacterDisplay.java

Yep, I'm aware of the protocol barrier to approach simulation in a language-neutral way. It's definitely much more powerful.. I've got some holidays coming up, so maybe I'll look at the protocol and see if I can't hide my Java stuff behind a protocol facade. Just out of interest, do you have the LCD emulated, and if so, what features do you support?

I have got quite a bit of code. But don't know if it's worth spending more time on. Quick description of what I have: First of all, I'm afraid I took an approach which is not language-neutral: it builds on the Java bindings. Given this caveat, I reasoned that the Tinkerforge APIs need to be maintained as much as possible, so my system produces (using code generation) Java interfaces and non-public classes for all bricklets. Most Java programmers are aware of "programming against interfaces" (cfr Joshua Bloch's arguments in relation to his Collection Framework), so in my Tinkerforge world, I write stuff like DistanceIR distanceIR = TinkerFactory.createDistanceIR(..); instead of BrickletDistanceIR distanceIR = new BrickletDistanceIR(..); (DistanceIR is an interface, not a class). TinkerFactory can produce real (bound to hardware) bricklets, or it can produce emulated (pure software) bricklets. So far, I've mainly spent time on emulating the components that I needed to get my cellar water pump system implemented: DistanceIR, DualRelay, LCD20x4 (also have Temperature, Barometer, AmbientLight). My cellar system polls all sensors every second, so I'm not using the callback mechanisms at all. So that's not currently supported in the emulated stuff.. (should be easy to add though). If a large proportion of Tinkerforge customers are using Java, then I wouldn't mind spending a few more weekends plugging the most obvious holes in what I've done (and releasing the source).. that's why I asked in another thread whether anyone knows what kind of language split exists in TF land?