@ Junko. My colleagues keep trying to persuade me to use a smart phone, my reply is I don't want a phone smarter than me. Seriously what I do need is a robust phone (or any other device) so like you I would prefer a word that describes the desirable attribute. At the moment the use of "smart" just turns me off.
DAC the conference and DAC the integrated circuit or IP block should both be pronounced "dack." The meaning will be clear from the context -- "Did you go to that awesome DAC party?" would never be confused with "this DAC doesn't have enough resolution to meet my requirements." :)
Where I work we already had trouble to fit Bluetooth messages that include the word Bluetooth in some of our infotainment products, and have used BT to abbreviate Bluetooth (for example BT Device connected) adding Smart would make those phrases even worse to fit! Replace T for S in our BT? No way!. For those I'd prefer the BLE abbreviation.
@Junko: I, for one, believe that BTSmart has a place and can be the energy-efficient alternative to WiFi in some applications -like the example I quoted elsewhere on Vehicular Area Network applications (I hate to use Smart Cars!) where movig vehicles can tag a stationary beacon for traffic management purposes. This can be done efficiently by BTSmart as it can do so with control plane alone whereas WiFi has to do both control and data planes.
@Frank: I agree with your observations... tacking on an IPv6 stack so Bluetooth can finally establish itself in personal area networks & elsewhere could have been described by other buzzwords by the marketing folks! BluetoothSmart implies the previous incarnations were dumber!
@betajet: I have come across many that use DAC for design automation conference, particularly those in the EDA companies. I am guilty of doing the same though I am fully aware of the long-held claim to this abbreviation by the digital-to-analog crowd!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.