User Interface?

Go To Last Post
74 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, you (joeymorin) are about 5 steps ahead of me. This is great stuff.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it me or was IrDa supposed to be the "next big thing" back in the 1990's? The plan was that electronic devices everywhere were going to be able to "talk to each other" by IrDa. Most PDAs, things like Palm Pilot (anyone remember?) and so on included IrDa so they would be part of this next great revolution. I think early blackberry's might have had it too? All this rather raises the question "where is it now?". I can't help thinking that things like range and light interference and just generally the fact that it took a lot of tweaking and was a pain to work with tolled the knell of parting ways for the technology. In this day and age it does seem that BT-LE and NFC are the kind of modern equivalent for letting two electronic devices have a "local chat" and they "just work".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am exploring NFC also. Due diligence and all that.

 

One issue that I have is access to NFC in smart devices. It is not clear to me how to transfer plain data as opposed to some standardized financial transaction. I cannot tell if the NFC API in the smart devices allows that.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NFC may currently be "too new" and the very name (N=Near) suggests it might not be the best choice unless the device can virtually touch (in which case why not simply a cable?) . I would have thought Bluetooth (low Energy) was the established link of choice and I think there's only about a million things written on the internet showing how mobile apps can access the Bluetooth.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My goal is to be able to configure my instruments without opening the IP65 enclosure.

 

A bit leery of BT after way too many glitches, hiccoughs, with BT. Connections that don't get made between desktop and laptop computers, totally fubar with BT earphones, and a lot more. It, what ever "it" is, has to "just work".

 

My idea with the IR link is a cover that fits over the enclosure (plastic). The top of the enclosure is transparent polycarbonate. An IR transceiver on the instrument board and a complementary one in slip-over cover would be around 10cm apart and positively located with respect to each other. The slip-over cover could include a USB interface (such as FTD232R). A smartphone app that talks like a terminal through the USB port could then access the instruments configuration interface and set time, date, sample rate, and a variety of other conditions. Such a setup would be far more tightly constrained than Palm Pilot or Blackberry.

 

NFC should (technically) work equally as well, or easier, since many smart thingies have NFC built in (no extra interface device on a USB cable). Having the user simply place the smarty against the front of my instrument enclosure (they are actually close to the same size)  would insure proximity. This is a solution that is really attractive IF the NFC API in Android permits something more than just financial transactions. Trying to sort out this one, also. An alternative MIGHT be to implement my own non-standard NFC link, providing both ends of the link much like the IR idea.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Wed. Aug 21, 2019 - 05:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Take a look at NFC beam:

 

https://developer.android.com/guide/topics/connectivity/nfc

 

There's a lot to digest here!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman -

 

THANKS for that hint about megaAVR 0-series. I was planning on switching to a ATmega4808/9 so that is particularly sweet. The MCP2150 and siblings include 64 byte packet structure and that would be a bit of waste (especially for power) in my application where "packets" vary from a few bytes to a maximum of 25 bytes. I was also wondering if the CCL block could be combined with one of the UARTS to implement the RZI encoding and decoding but having an IrDA module built into the UART simplifies all that.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies -

 

Ahh, that is just the sort of thing I was looking for, re NFC.

 

Wow, strong hits on TWO obscure topics, IrDA and NFC, in one thread. Freaks are the best!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
A bit leery of BT after way too many glitches, hiccoughs, with BT. Connections that don't get made between desktop and laptop computers, totally fubar with BT earphones, and a lot more. It, what ever "it" is, has to "just work".

From what I have used BLE modules(ie. Rn4871 & BLE112) in my projects "it just works", I haven't had any connection proplems, once the module is in range I'm allready connected to it before taking phone out of pocket. API for ble in Android is well documented aswell, you implement couple callback methods and you are set, BLE stack will handle all the low level stuff for you.

ka7ehk wrote:
This is a solution that is really attractive IF the NFC API in Android permits something more than just financial transactions

There is NFC p2p mode in Android NFC implementation, but i think it's mainly implemented for android to Android communication in mind(Android beam).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, JoniS!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How relaxed is req. 4. ?
Snd does it split in som ways to stationary part and non fixed installation ? :)

Last Edited: Thu. Aug 22, 2019 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The requirements list has shifted substantially.

 

It was originally written thinking that the "optimum solution" would be something like a display and keypad. The shift has been to something external (such as smart thingie) and a very low power link that does not require opening the enclosure. 

 

Background: current device is configured via USB terminal. This requires opening the enclosure, which is problematic in a variety of only slightly extreme environments. The goal of this thread has been to find a way for the next generation product to be configured in the  field with a closed enclosure.

 

Summary: A variety of wireless technologies have been suggested and explored. Current technologies at the top of MY list are NFC and Infrared (such as IrDA). BlueTooth is a close third on my list. Others may rank things differently. 

 

Item 4 in the original requirements (unit cost) has not been a big factor in the discussion. A solution involving a short-range link and external smart thing will cost a lot more than the specified amount but, in many applications, that will be "amortized" across multiple units (single interface device serving several instruments). 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Aug 22, 2019 - 03:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there currently an LED indicator of some sort on the existing design?  If so, consider an unusual approach:

http://www.merl.com/publications/docs/TR2003-35.pdf

 

Might require an extra I/O pin.  If you have one, and don't mind a green-wire mod, you could retrofit existing designs to provide a two-way link.  The other end could be a stand-alone device, or a bridge to a smart thingy.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hm, I actually have 3 red/green LEDs (one for each accelerometer axis). Might be able to use one for transmit and the other to receive?

 

Gotta look at this!

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps an alternative is a simple IR LED and IR photo transistor?

 

You don't have to transmit a signal across a room with varying amounts of sunlight, florescent light, tungsten light, halogen light, and various LED lights, all providing "noise" to your signal and decreasing your optical S/N ratio. 

You have the ability to align the LED and the Photo transistor physically, and your separation is only several mm's, through clear or slightly tinted Plexiglas. 

You also have the ability to mount the pair inside a lid that covers the data collection box, blocking out the ambient light.

The Photo transistor can feed the analog comparator module on the AVR, and simple UART Comms would likely work just fine.

 

Mount two pairs for bi-directional comm's.

 

Pack your data in a "data packet", with a checksum or a CRC, and use a simple got it, or re-send it, Protocol, with an error timeout, and a few "Command" packet options.

 

Weekend Project! wink

 

JC

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cross post.

 

I suspect a true Photo transistor will be MUCH easier to configure for reliable communications that using a "normal" LED biased, filtered, amplified, etc., as a receiver.

I suspect you don't want a bunch of analog front end circuitry just to use a normal LED as a receiver, that would be a fun learning project, but not a great option for a commercial product.

 

If you end up switching to an Xmega for Ver II of the product, have a look at the different models and their analog comparator.

IIRC, some of them have software adjustable window detectors for the analog comparator, i.e. a fancy Schmidt input, where you can configure the hysteresis, and what action triggers the interrupt, (signal in window, higher than window, lower than window, etc., which makes for a "reverse logic" window, where the window is the dead zone, i.e. a classic, but adjustable, hysteresis input).

 

JC

 

Edit:Typo

Last Edited: Fri. Aug 23, 2019 - 12:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

I suspect you don't want a bunch of analog front end circuitry just to use a normal LED as a receiver, that would be a fun learning project, but not a great option for a commercial product.

Don't need it.  The paper I linked shows clearly how it is achieved with only the LED, a resistor, and two I/O pins.

 

Agreed it is not the 'best' solution.  I mentioned it only because it may be a means of retrofitting Jim's existing products if that becomes desirable in the future.  For his new version (being built anyway as there are other enhancements apart from external config) a purpose-built solution is more sensible.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Likely spacing between an emitter and corresponding receiver is about 3cm of which a few mm is clear polycarbonate.

 

Some serious testing seems in order.

 

Thanks

jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We used a panel led as a detector to measure ambient light & control backlight---worked quite well (of course, easy compared to moving bidirectional data).   I had another project where I wanted a status "blink code" indicator; was told "NO" the customer won't allow any change or additions!!!...so instead,  to the user, the power on LED looks like it is just on, but is actually repetitively streaming just a few invisible bits.  I could use a scope & photodiode to check that certain internal modes are in effect & a driver current is within spec--no need to tear apart the sealed unit for diagnosis.  I wonder how many products do this without our knowledge? 

 

For the fresh design effort, adding a photodiode is probably the easiest route, less hassle & costs a 10 cents.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just reviewed the article that joeymorin linked. Turns out that it won't work in my present case because the LEDs I have are bi-color. The two different LEDs in each package are connected "anti-parallel" so there is never a configuration in which one of the diodes will work in reverse bias. So, that means that the current design stays as it is. Besides that, I doubt that there is enough code space to implement a software UART, or equivalent.

 

And, for the new instrument model, a proper IR sensor is really the way to go. You can get them with all the needed signal conditioning built in. So, there are lots of choices down that road (including NFC, etc).

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well it was a long-shot anyway...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

On the idea  of  NFC, there is a Design News CEC online class-series scheduled for September that describes using smartphone NFC to control devices.

 

https://www.designnews.com/conti...

 

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking at NFC awhile back, the easiest solution was NFC chips that had some onboard EEPROM (could be flash) and I2C comms to a uC. Reading and writing to the NFC chip was done to the internal memory of the NFC chip, the uC would then read/write the contents of the NFC chip via I2C.

 

Not all phones come with NFC, NFC is still a feature limited mid-end and up phones.

 

For BT you have BT Low Energy modules, I do not know the idle power consumption but during active tx/rx the current consumption is about 25ma.

Pages