cheaper large instrument displays - mast mount

Shaun and Co, looks like you're doing a great job - keep it up. If you could come up with a DIY instrument kit you could tap into a huge boaters 'winter projects' market.

I'd buy one.
 
One thing you could consider using for a display is a Kindle - it's now been thoroughly hacked - see http://wiki.mobileread.com/wiki/Kindle_Hacks_Information#Jail_break_JB - and would be ideal as it is designed for daylight readability and is a very low power device. Refresh rate isn't instant, but probably good enough. With the new model costing £69, it's a lot of screen area for the money - and it has built-in WiFi, so it should be easy to wire up.
 
One thing you could consider using for a display is a Kindle...

My mast is a pretty damp place. A Kindle wouldn't survive the first wave.

In my opinion the hard bit about a project like this is not the hardware, software or display. It's making a rugged waterproof box with buttons and a cable entry that will protect the contents for a decade of getting regularly doused by high speed salt water. If it leaked before that I would feel hard done by.
 
My mast is a pretty damp place. A Kindle wouldn't survive the first wave.

In my opinion the hard bit about a project like this is not the hardware, software or display. It's making a rugged waterproof box with buttons and a cable entry that will protect the contents for a decade of getting regularly doused by high speed salt water. If it leaked before that I would feel hard done by.

I agree a Kindle isn't the answer, but an e-ink display panel (which is VERY readable under a lot of conditions) might be a good idea. The refresh doesn't have to be as slow as a Kindle - it is deliberately slowed by the introduction of a clear cycle on a Kindle to improve the display quality. THe e-ink display would be mounted in a waterproof enclosure, just like an LCD or other display.
 
My mast is a pretty damp place. A Kindle wouldn't survive the first wave.

Just stick it on with gaffa tape, it'll be fine...:p

But can you buy e-ink displays in the right size?

AFAIK, the Kindle is marketed close to or under cost price, in order to sell e-books, so I doubt if you could just buy the panel cheaper. I think the refresh rate of a Kindle would be adequate for most yachting data, just needs someone smart enough to hack it to suit. The approach I'd take would be to use .jpg images and just swap those around as needed.
 
My mast is a pretty damp place. A Kindle wouldn't survive the first wave.

In my opinion the hard bit about a project like this is not the hardware, software or display. It's making a rugged waterproof box with buttons and a cable entry that will protect the contents for a decade of getting regularly doused by high speed salt water. If it leaked before that I would feel hard done by.

I agree, this is always the most difficult part of any electronics project.

The minimum enclosure rating if IP68 with IP68 rated cable glands for cable entry.

I fitted some video cameras on my mast in IP65 plastic boxes with polycarb lids and still get condensation inside the box lid. When I have time I will be making stainless boxes with gasketed polycarb lids bolted on with a series of screws around the flange similar to how I did these covers

Also consider that this type of unit could also be used for other instruments like the AIS display you did a little while ago which I hope to start on next year.
 
But can you buy e-ink displays in the right size?

THIS looks like a good starting point. The displays look like costing a few 10s of dollars. Various sizes/capabilities, including segmented displays.

Advantages - no power required for static display; power only required to change the display. Readable under any lighting; wide angle of view.
 
THIS looks like a good starting point. The displays look like costing a few 10s of dollars. Various sizes/capabilities, including segmented displays.

Advantages - no power required for static display; power only required to change the display. Readable under any lighting; wide angle of view.

Readable under any lighting except darkness. I think data at the masthead is likely to be dynamic with at least a 1s refresh rather than static unless you want a device that shows you a picture of a kitten or something.
 
Readable under any lighting except darkness. I think data at the masthead is likely to be dynamic with at least a 1s refresh rather than static unless you want a device that shows you a picture of a kitten or something.

I think every display technology except power-hungry LED displays suffers from the darkness disadvantage :) A couple of led bulbs and a photocell would sort that out.

Agree that you want to be able to refresh at a 1s rate; that's not a problem with e-ink. But if the data happen to be changing slowly, then there would be a potential power saving.
 
I think we have some fascinating diversity here.

For some the electronics and actually making it work is the 'black art' impossible bit.

For other it is the housing and waterproofing

For some the general capabilities of the technologies avaialble.

As an aside, i spent the majority of my trip to SIBS yesterday looking in great detail at Raymarine and B&G instruments to work out how they do it, It was quite a suprise.

Raymarine LCd's in the new i70 range and their multifunction displays are off the shelf, I have the manfacturerer and their specifications, what has surpised me is the cost of the displays (they are low cost LCD,s

There really is nothing special about the housing, they are essentially a plastic box with a sealed glass section for the LCD to show through, a bezel so that you cant see the edge of the LCD and cable entry, the ratings for most are IPX6 or IP66 (very few are set for submersion, excepting tacktick)

Having spoken to a few manafacturers, i now dont see the housing as the big issue (i did previously) I now understand the low volume production methods and costs and it is is currently well within reach for this project, it realy has suprised me once you start to dig.

For me i am learining about LCD's and all the technologies etc are now becoming clear, it seems TFT would be ideal, the most flexible but much harder to program, develop and test with. The STM32 processor is starting to make a tiny bit of sense, although i still am not really sure if i need to buy a programmer and JTAG (debugging) was a new one on me last night.
As for the C programming language, or assemly, Hmmm..it would seem i have a long way to go here other than writing 'hello world'

In short

Housing - Pretty Much resolved and can be done
LCD - Getting there, TFT would be lovely
PCB/Circuit design - A lot to be learnt
STM32 - A lot to be learnt
Programming STM32 - May as well have never written a line of code before

The overall process for small scale manafacture - a lot more in reach than i ever thought possible and well within reasonable costs

Do we need to divide into our specialist areas and progress from there? (although i have no idea what mine is ;))
 
The STM32 Discovery boards have a ST-Link on the board. ST-Link is the ST version of a JTAG debugger hardware. The Discovery boards cost less than a ST-Link JTAG debugger on its own. That's partly what makes them amazing value.

You only need a JTAG for debugging during software development. Although a JTAG can be used for flashing your software on the chip, all SMT32 processors also have a serial interface for flashing software. This interface can't be used for debugging though. Don't get hung up on JTAG. You don't need to be aware that the debugging interface is JTAG or know anything about it. It's just an industry standard so things talk to each other. As far as the user is concerned, you plug it in, select the appropriate debugging hardware (i.e. ST-Link) in the IDE you are using, and off you go.

The JTAG drivers and flashing software are free downloads from ST.
 
Last edited:
I just wanted to state my interest and willingness to do what i can for this project.

I have been following it since its origin and am happy to contribute - most likely in terms of testing and R & D.

4 things:
1) Have we any idea of how many people are interested in this as we stand? i.e. numbers who would stump up for a first go? That would give us an idea of how many on a first run of orders of casing, pcb, etc.
2) Are we going to take this out of the PBO forum (to the wiki) or double post on each site. I just want to know which to follow and make sure I'm not missing out on something!
3) It strikes me that we will be very lucky indeed to get this right the first time, so we need to invest in some trial (and errors).
4) I have a particular interest in wireless tech on the boat. It resolves some issues (although creates new problems as well).

Should we begin to establish a tech standard that we work towards on Model 1 ?

Just some thoughts !!

Jaba
 
Programming STM32 - May as well have never written a line of code before.

ST provide a lot of low level libraries to help. CooCox, a free dev tool for ARM Cortex processors, integrate these libraries.

The CooCox IDE provides a lot of help. It doesn't support all the STM32 processors, but many of them it does. The paid for dev environments like Atollic TrueStudio cost £1000's.

No assembly language is needed. It can all be done in C. The advantage of using an ARM based processor is that once the drivers have been written then the C programming in layers above will be very similar to writing C on a bigger computer, i.e. standard ANSI stuff. Smaller processors like PICs and Atmels have their own slightly weird version of C to fit in with the restricted processor capabilities.
 
Thank you Angus, then penny has fully dropped, i had planned to spend the evening making sure but you have saved me hours..

I dont need to spend £30 on a ST-Link programmer/Debugger at the moment, i will do though if i move to an eval board and then a custom board (that's a nice bit of cash Saved which i will put towards the eval board with LCD)

I had seen Coocox and had planned to download it, I reviewed atollic and set the limited version to download (32kb Limited code i think)

Is Coocox a fully fledged IDE and Compiler? it looked to be (for those of you that don't know, IDE is integrated development environment, the place where you write code, the word processing equivalent would be word, a compiler changes written code into something that a computer can read at a low level, think of it as binary 1's and 0's)

:) i was up for a couple of extra hours this morning reading about JTAG, nice to know i dont need to know anymore about it :) (it did help me sleep though)

Jabamusic

I am in for at least 4 if we can make this work, and suspect that ther may be some legs in this looking around SIBS yesterday. I am a great fan of wireless and would love to use more of it :)
 
CooCox does not contain a compiler, it is just an IDE based on Eclipse, but it is tailored for ARM Cortex development. You get the GCC ARM or Code Sourcery compiler from somewhere else. It's described on this CooCox page...

http://www.coocox.org/CoIDE/Compiler_Settings.html

The compiler is also free. Once you have the compiler and CooCox installed you need to tell CooCox where the compiler is installed on your system. I suggest, as does CooCox, you use to ARM GCC compiler rather than the Code Sourcery one.

CooCox is not as fully featured as the professional dev environments like Atollic (eg. no C++ support), but it is fine for this project. It has a lot of the clutter features of Eclipse removed which makes it ideal for beginners. It's all done for free and I know they struggle for funds, so I would suggest if you use it and the project comes to fruition, then make a small donation for every device built.

The 32k limit on the Atollic trial development environment is too small to be useful. They have only done the same as CooCox anyway, i.e. modified Eclipse and integrated a free compiler.
 
Last edited:
thanks angus..i will setup tonight and see if i can manage a 'hello world' (any chance of a sneaky peek of some of your code so i can see what i am up against? fully understand if you say no, i really like the idea of a small donation to Coocox...it would an ethical thing to do :)

I never thought that i would be learning this, i doubt my skills will make this a reality but if i can contribute/help/understand etc then i will give it a damm good go

Now to order the dummies guide to C (C is a programming language)

Is there a consensus on the forum here or the wiki? my thoughts are the wiki would be more flexible, although people dont always like to check multiple places. would the wiki be best used as a 'repository' of information, code, research and documents?
 
Do you have a dev board? If so, which one? Printing hello world is too complicated as a first step in embedded world. Flashing a led is normally the first thing to do.

This is the basic procedure if you have a ST-Discovery board...

1) Install CooCox and the GCC ARM compiler.

2) Install the ST-Link driver. Should be on a CD with the Disco board.

3) Start CooCox. Tell it where your compiler is installed. It will be something like C:\Program Files\arm-none-eabi-gcc-4_6\bin

4) In CooCox on the Repository window click ST

5) Choose your processor. See the Disco board datasheet. You need to get exactly the right one.

6) Now select components. Tick C Library. CooCox will ask if you want to create a project. Select Yes. Give it a name. The default path will do for now. Finish.

7) Now select CMSIS Core, CMSIS Boot, RCC, GPIO from the Select Components window. These are all peripheral libraries provided by ST to make things easy. Close the Repository window.

8) Hit F7 to compile.

9) In the Project window in CooCox find main.c and open it. You should have an empty stub file with just a while(1) loop in it. You now have a working program which does nothing, but can be compiled. Note that bare bones (i.e. no operating system) embedded apps like this must never exit from main as they have nowhere to go.

10) If you got that far, replace all the code in main.c with this...

#include "stm32f10x_gpio.h"
#include "stm32f10x_rcc.h"

int main(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
int i;

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); // *
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All ;
GPIO_Init(GPIOB, &GPIO_InitStructure); // *

while(1)
{
GPIO_WriteBit(GPIOB, GPIO_Pin_8, Bit_SET); // *
for (i=0; i<1000000; i++);
GPIO_WriteBit(GPIOB, GPIO_Pin_8, Bit_RESET); // *
for (i=0; i<1000000; i++);
}
}

...and compile again with F7. You will need to adapt the lines marked with // * to get the port
and pin for your board that has a LED attached.

11) To debug...connect the dev board via USB to your computer.

12) In CooCox find the debug confgiurations button and click it (2 orange cogs).

13) In the dialog click the <project name>.configuration.

14) In the Hardware Adapter choice choose ST-Link

15) Click Apply, Close

16) In CooCox, CTRL-F5 or click the debug button. It should start to run and stop in main().

17) Click step over, or go and it should run.

I haven't tried the above for the debugging bit, it's just from what I remember, so it may not be exactly right. But if you get the project to build, that's a good first step.
 
Last edited:
Thank you so so much Angus,

Oddly i think all of it makes sense to my brain and i can see how the code is structured/works.

As for Dev board..i have ordered the cheap £8 one from RS that you referenced on Saturday...i can't wait for it to arrive :) and start learning/playing

i did find an intersting site during this journey http://www.djerickson.com/bbus/lcd.html
looks like someone was trying to create their own protocol for communications, it would have been great had they continued and commercialised it
 
Top