Importing Images into Altium Circuit Maker

Premise

One of the things Altium Circuit maker current lacks (see a short review here: Altium) is the ability to import images into Altium’s board design.

There is a fairly painful way to do this via making an image into a font, installing the font to your computer, and then “typing” it in to get the image to appear. This is.. sub-optimal.

However, one can import/export from a .csv file into vertices of a polygon pour. This could enable importing images into Altium.

Approach

The rules for polygon pours seem to be as follow:

  • polygons are filled when vertices form a (clockwise oriented) closed surface.
  • Lines that cross back on themselves have a zero thickness, and hence don’t appear.
  • The entire list must start and end on the same vertex.

So, we could make a script that generates a list of vertices, and import a (somewhat blocky, 1 bit color image) in this way.

Here is an example done by hand (note the thin lines do not appear in a gerber export!). The lower left square is drawn first, then the lower right, and lastly the center square.

Hand Desgined Image into Altium Circuit Maker

The starting/ending point is always the lower left origin.

The vertices for just that simple shape are fairly lengthy:

Vertices

Index X (mil) Y (mil) Arc Angle (Neg = CW)
0 -1550 -700
1 -1550 -690
2 -1550 -680
3 -1540 -680
4 -1540 -690
5 -1550 -690
6 -1550 -700
7 -1540 -690
8 -1530 -690
9 -1530 -680
10 -1520 -680
11 -1520 -690
12 -1530 -690
13 -1540 -690
14 -1550 -700
15 -1540 -690
16 -1540 -680
17 -1540 -670
18 -1530 -670
19 -1530 -680
20 -1540 -680
21 -1540 -690
22 -1550 -700

Notice above, we do have the ability to specify Arc angle for each segment, but that is a level of complexity I will likely avoid in the near term.

It speaks with a hiss

My favorite tool in the bag of tricks is Python, mostly due to avoiding the need to compile, and lots of good libraries. This is especially true of graphical manipulation, which we will need if we want to get images into Altium Circuit Maker.

I used Python 2.7 for this, on Windows. (you will need the python pillow library, execute “python -m pip install pillow”)

See the full code here:

https://github.com/ibaranov-cp/ImGen_Circuit_Maker

Open the “ImGen.py” file, and change the file name, size and inversion as needed. Once the program is run, it will generate a .csv file with the same name as the image input. This can then be imported into the polygon pour.

Menu for  Image into Altium Circuit Maker

 

result

Test Image into Altium Circuit Maker

The lines returning to the center can be seen above, however they do not appear on a Gerber file.

What’s the catch?

There’s a few downsides to this approach over the image-font-import method:

  • Resolution is low. For your sanity and RAM usage, I don’t suggest using any image over 20×20 pixels.
  • This looks much nicer with images that are blocky to start with. I’ve used this to generate QR codes, barcodes, etc.
  • Images are placed at the origin, but can be moved later

Future Work

  • Use Arc Angle to make smoother images
  • Generate triangle instead of squares, and take into account 50% filed cells, instead of only black and white.
  • Automate generating multiple layers (top layer, top solder, top mask, silkscreen) to generate 4 color images
  • Optimize path-ing algorithm to reduce path complexity

Ideator – The business idea generator

Hearing tons of investor-speak “we are the X of Y” “We revolutionize X with technology Y” I decided to make an automatic generator for such things.

Every time you refresh this page, you should get 3 elevator pitches.
Take a few minutes to try and defend each one, should be good exercise to get the innovation juices flowing
Have fun with the generator!



We will revolutionize sharing for college students
We leverage beta software to improve lean

We are making the flexibility world more complexity with the cloud

Protest Phone – Part 1

This is the rough draft of the letter for the Hackaday 2016 challenge with Naim Hilal:

SMAC

Go check out the project!

These ramblings are left here as reference.

Protest Phone is a series detailing the idea, design, and hopefully realization of this idea that has been in my head for months.

As we have seen in numerous recent protests and uprisings, social media and instant communication are crucial to organisation of the group. The means to quickly disseminate information to participants means larger numbers are able to arrive and organize. We have also seen governments and organisations start to realize this, and deploy counter measures, ensuring that protests are stopped before they get started, in a more PR friendly way than force.
What we purpose is a phone that is resilient to both surveillance, trust network infiltration, and jamming. It is also cheap, resilient, and can function without an energy grid. Those last two points are crucial for it to work in actual protest situations. The phone would be used in text only mode for the majority of use cases, with audio and video possible when connected to a normal network, or when priority/reputation is high enough for the user (more on this later)
Lets start with Jamming. The phone uses a mesh network topology where every message sent from each device is packetized and routed by any available route. This protects against a centralized take down of the cell infrastructure, and is somewhat resilient to jamming, as it can route around trouble areas, but it is not totally invulnerable.
To make the phone almost invulnerable to jamming, we turn to the backup RFID sneaker-net system. In heavy jamming situations, users would touch phones together with all their closest neighbors, thereby passing on messages like nodes in a network. This would take roughly 10 hops to get from end to end of a large crowd, so as long as people tap phones ~10 times a minute, communication latency would be fairly low. The power requirement of jamming near range, shielded (by the interlocking bodies of the phone) RFID communications would be so large, they are well outside the range of conventional or military hardware.
Surveillance is the easiest to explain. With a modern, public-private key architecture, encryption of all message contents should be about as secure as currently feasible. Key exchange would take place between phone users for private conversations, and shared public-private key groups would enable messaging boards, etc.
Trust network infiltration is a more difficult one to get totally right, and so far is fairly underdeveloped. The issue with public-private key exchange, and with covert networks in general, is that if an informant is place in the organisation, the group is exposed. To solve this issue, my current thoughts are to use a similar, if not identical, model to the bitcoin blockchain. Here, the blockchain would be used to authenticate that messages actually came from the user the message claims, and to accrue reputation for users.
The idea here is that when messages are passed on, the user doing the passing gains a little reputation. Positively acknowledging the receipt of a message intended for you also gives the sender some reputation. Thus, to send messages, users must be actively passing messages on, which acts as an incentive for snearker-net message passing, and generally good behavior. If the recipient sends a negative message receipt, this decreases the senders reputation, effectively preventing message spamming. This also conversely makes the most convincing voices (the organizers or leaders of a protest) the highest priority messages in the network, as they would naturally have the highest reputation. Reputation donations would also be permitted, along with paying more reputation for higher message priority, or higher bandwidth requirements.
Users would have their own, private, encrypted “phone book” containing identities that they have exchanged keys with. Exchanging info would be as simple as taping phones together, and pressing accept.
Lastly, voice messages or even images/video would need huge bandwidth and packet fragmentation. This would only be possible for users willing to pay a lot of reputation.
The network would maintain anonymous information on the amount of active modules, to help balance load and set the blockchain specifics (size, distribution, etc). New networks would be spun up for every event, and most likely dissolved afterwards.
Hardware:
The design is centered around the ESP8266. This chip is low cost, high bandwidth, flexible, and is fairly powerful.
The system contains:
– solar panels
– li-ion battery, battery charger and management,
– ESP8266,
– RFID transceiver + antenna,
– low power touch screen,
– speaker + mic + ADC,
– possibly low cost camera.
Software:
– Simple UI with on screen keyboard
– Encrypted top to bottom with public-private key exchange
– Bitcoin-like blockchain implementation
– mesh network + packetizing protocols
Mech:
– Strudy plastic casing, mostly waterproof
– Clear back for solar cells
– About the size of a large smartphone (7″)
IP:
All designs are open source, and can be made by anyone with access to parts. Parts are specifically chosen to be hand solder-able and low cost.

Ultrasonic Amplifier – Part 1

This ultrasonic amplifier project comes in two parts, design, and testing. Today we will cover the design and rational.

Idea

Many animals emit high pitch noises, what we call ultrasonic, that is beyond the hearing range of humans. Two such animals I am interested in are rats/mice, and bats. I want to hear the noises that they emit.

The classic approach that many bat detectors use is to amplify the signal coming from an ultrasonic microphone, then just treat it as a square wave and divide it down into human hearing range. This seems a little cheap to me, as you are getting a severely distorted noise, that does not carry amplitude info at all. Imagine a speaker screeching in distortion because someone set it too high, that is essentially what you are hearing from this detector.

My thought was, why not do a FFT (or even better, an FHT) to get the spectrum of the sound, compress it if needed, and then shift it down into human hearing range. Lastly, we just do an inverse FFT/FHT, and voila, truthful sound at roughly the right speed.

http://www.alwayslearn.com/dft%20and%20fft%20tutorial/DFTandFFT_BasicIdea.html
Attribution in alt text

 

ultrasonic amplifier Circuit Design

First things first, we need to amplify the signal from a ultrasonic microphone. The ultrasonic amplifier works in three stages, with the final stage having an adjustable 1-100x gain. When selecting the gain per stage, don’t forget to consider the gain-bandwidth product of the amplifier! The 1/2Vcc below is generated by a simple resistor divider, which works fine in this use case, as your op-amp input impedance is very high.

Ultrasonic AmplifierThis signal is then fed to a single stage Sallen-key filter, to remove any signals above ~90kHz, and then into an ADC. Remember to always chose an ADC with a sampling frequency at least 2x your highest signal frequency, this is known as the Nyquist rate. In reality, you want a sampling frequency of ~5x or more, to get a decent picture of the sampled waveform.

Ultrasonic Amplifier ADC

The signal can then be read by a oscilloscope for testing, and fed via SPI to a microcontroller. I will be using the ESP8266 for the FHT and IFHT steps later, possibly showing the waveform in a webpage.

Circuit Layout

The circuit layout is a fairly straightforward 2 layer board. The only trick for this ultrasonic amplifier is that the microphone is mounted horizontally to save on board space.

Ultrasonic Amplifier Layout

Now to wait 2-4 weeks for delivery and assembly 🙂

As always, these projects are open source and usable for any reason (preferably with some attribution). You can find the designs on my Altium circuit maker page:

http://workspace.circuitmaker.com/User/A590ACC4-C8D6-4893-ACF8-6250986C2EBF