eList
The concept is the device sits on the charger and receives entries to the list using a wireless solution (likely to be Bluetooth initially).
Entries can be added or subtracted using a web server application, that formats and transmits the list contents to the eLIST.
see the previous posts beyond the Phone - eLIST progress , Beyond the Phone - eLIST - KOBO Touch , 5W Load Schematic
Hardware
As I said in the KOBO Touch post, the BADGEr display is too small, and the larger ones haven't arrived and no ETA has been provided.
So for the meantime I've concentrated on the other parts and trying to sort out the software side.
Software
When I started this project I wasn’t aware of the shopping apps that existed, however after looking at some of them, ease of use became paramount.
Regardless of the hardware there are two parts to the process;
- the entry/review of the list, and
- using it while purchasing the items.
For the later part, after purchasing a BADGEr, a few issues became apparent which couldn’t easily be overcome.
- The display was quite small, meaning scrolling was required
- The page change was quite slow, possibly to extend battery life
- The device needed a Qi receiver, bluetooth, battery and suitable charger added.
- The exposed design wasn’t suitable as a long term solution.
I’m still very keen to produce a dedicated piece of hardware, but sadly I’ve spent far longer on the software side than I planned, plus the display delays, so I need to plan that it may not eventuate before the challenge is up.
This meant the use of a KOBO eReader was a more viable option. It already had a large fast (and sharp) display, battery, charge management, case and the built-in wireless and browser makes the task easier.
The OS can be modified, but by using the built in Browser, a simple web page could display the list, and means its easy for someone to replicate.
I have ordered a Qi compatible universal charging pad which plugs into the micro usb socket, and means the warranty is not invalidated on your new KOBO, but I think the ship got lost or it run out of wind.
It arrived just before I pressed publish ... but I have some testing to do before I report on its performance/suitability
I fully expect the power and efficiency to be less, and yes it isn't using the TI or Wurth products, but for this end it's something anyone can use.
For the first part, a Raspberry Pi acts as a webserver. This monitors the Wireless Transmitter and can let users know if the eLIST device is still connected.
I have yet to tackle this part, but I’m confident that if the hardware link doesn't work, I have another method that should work.
Rather than rely on additional software or Javascript, I elected to have the RPi produce a text file, which can be used with any hardware.
While this sounds simple and should be, my web software skills have shown to be wanting. As time runs out, functionality may override the polished presentation.
I wish I'd run across Peter Earle's blogs earlier, as I struggled with some of the strange syntax of PHP.
Of course the www was just that (wild, wacky, way out), with varying solutions by very knowledgeable people, but of limited help to what I wanted to do.
I can honestly say I've spent weeks more than I wanted to, to produce something that looks like its 5 mins by someone who knows what they are doing, .... but I have learnt some things along the way.
I intend to document the setup of the webserver and the static settings, but after I cull anything not required and repeat the process to be sure I haven't missed something.
Index page, which because it runs a php script has to be called index.php
We tend to have a set list of common items, and I decided the list would be limited to 50 items.
Rather than selecting items and adding them to the list, I decided to simply tick or un-tick items on the list but allow extra items to be added.
The 'Show list' page and the result after you press Send
One of the quirks that caught me for a while was entries with a space.
While it displayed correctly, the result in $_POST truncated it to just the first word.
After untold hours searching I finally found it required the extra single quote around $partAa[0] to make it work.
(I refused to bow down to the other suggestions of avoiding the space and using underscore!)
<input type="checkbox" name="List[]" value= "' . $partAa[0] . '" checked ="1" >
I did note that the checkboxes are very small on the KOBO, but luckily in my other searching I found a way to allow the whole text to act as the tickbox. ( HTML label tag )
The idea is to add 'id= xyz' and produce a 'label' that matches the id. This means the whole word acts like the checkbox.
print '<td>' . $ListCount . '</td> <td> <input type="checkbox" name="List[]" value= "' . $partAa[0] . '" id = "' . $partAa[0] . '" checked ="1" ><label for= "' . $partAa[0] . '"> ' . $partAa[0] .'</label></td>';
Sorting
When I was looking the the Shopping Apps, there were several sorting methods, but the layout in the shop has its own order, hence most sorting methods are wasted.
Using a csv text file, it’s very easy to setup and change it around to suit, and if you wanted to get clever you could allow different sort methods or lists.
Bread,0
Milk Green,1
Milk Blue,0
Marg,1
Ham,0
The script just reads each line in the list and if ticked is added, so whatever order the original file, is the order of the list.
Messages
My idea also allowed for the eLIST device to display messages, and I’ve been working on incorporating this at the same time, using the same principles.
Message entry screen
I’m currently trying to decide on how to handle messages that are no longer relevant.
- If a message suggests ‘Home at 1800’, when is it no longer relevant?
- If it has no ETA how can the system know its run out?
The second decision was how many messages. Do you set a number and once exceeded refuse to add more?
In the meantime I've simply allowed for 4 messages as seen in the Index Page (above) and users can add extra text to the message.
I may end up cycling the messages, and like the list, the message is text based to suit a wide range of hardware.
Progress
Like any Engineering project, the bulk of the work is in the planning, and the more planning the less resolving of unexpected outcomes.
For this challenge I didn’t have an existing design or idea to expand on, hence a couple of weeks were spent in refining the process, outcomes and the methods to achieve these.
I've been reluctant to post 'nothing' type reports, so this update is a compromise as well.
As you can see, most of the screen shots are pretty utilitarian at the moment, but they work to test functionality.
Any project needs good documentation, and I’ve seen commercial projects where it comes well after the project goes live. (and much complaining from us trying to fix it)
IMO this tends to reflect a lack of solid planning at the design stage.
I’m pleased to see many of the element14 Challenges have good documentation during the challenge, along with ideas being exchanged.
Mark
edit
My other posts Wireless Challenge .... Beer Tap (the other bit) - 4 Assembly Wireless Challenge .... Beer Tap (the other bit) -3 Wireless Challenge .... the other bit -2 Wireless Challenge .... the other bit Beyond the Phone - eLIST progress 4 (Transmitter modifications) eLIST progress 3 eLIST progress 2 , eLIST progress , eLIST - KOBO Touch , 5W Load Schematict