Archive for the ‘Magus – behind the scenes’ Category

The Magus board

Thursday, June 9th, 2011

Magus board close-up

Magus board close-up


Someone showed me a message board which is similar to the one we use at Magus ? The panic status board. It?s a big board that shows the ?panic? status of the group. Emails that need to be followed up, number of days to the next major deadline, who is holding up development etc. The person who?s name appears at the top has the highest panic rating and is most probably the bottle neck. The person who?s name is never on the board is probably not working very hard at all so the best is to try and position yourself somewhere in the middle.

The focus of the Magus board is not to ?create panic? although from the info one can derive who has more on their plate. The other difference is that it does not require electricity, it works 100% mechanically!

One of our engineers came up with the idea after realising that (all though everyone?s work is already stored and tracked in JIRA) there was a need to show everyone what is happening with Antenna Magus – the current state of development; what is planned for future releases and what everyone is busy with. This would also invite different teams (like marketing who isn?t much involved in low level design) to give their input during early stages of development.

We bought a second hand free standing double sided notice board and modified it with wooden rails to hold small cards. We painted different horizontal colours which represent different stages of development and we hanged vertical dividers to separate different releases. Each card represents a different antenna or transition. It is printed on photo paper, each with a picture, title and a small sticker showing who is responsible for it.

Before an antenna or transition is chosen to be included in a specific release it is placed on the back of the board where its life cycle begins. Once it gets chosen it is moved to the front and placed in the appropriate vertical (release) and horizontal (development stage) positions. As work is done, it slowly progresses to the top of the board until it is ready for release. Once released the card is removed and archived.

I?ve seen lots of management ideas which try to involve various individuals but fail for various reasons. However this is not the case with the Magus board. It has lived through numerous releases and while writing this post I saw a few engineers moving their antennas cards and inspecting the board.

Front view of the Magus board

Front view of the Magus board


Back of the Magus board

Back of the Magus board

Author: Robert Kellerman

Birds eye view of Magus offices taken by 2 cameras mounted on an L-39 Albatros model aircraft

Tuesday, October 26th, 2010

One of my colleagues spend most of his spare time building gadgets from components that he imports directly from Hong Kong. He recently bought an L-39 Albatros 50mm EDF remote controlled aircraft and mounted two imported mini video cameras on the front and back of the aircraft to capture the front and rear facing views. He made a short movie (see below) of a bird?s eye video taken of our offices and surrounding area in Stellenbosch, South Africa.

I was very impressed by the quality so I asked him about the cameras. Apparently these mini cameras aren?t very expensive as they are basically reconfigured cell phones without the keypad and RF components and are mass produced in +- one million batches. The only drawback is that due to the nature of the cell phone industry the components change all the time so in 6 months one wouldn?t be able to get hold of those specific cameras any more.

Here’s the view taken from the ground, http://www.youtube.com/user/megatesla#p/a/u/2/pyGd3DKDlD0. Note how fast the aircraft is moving!

Author: Robert Kellerman

There must be an easier way to read off design values from an IEEE paper

Wednesday, August 25th, 2010

Illustrating the traditional graph tracing method.

Illustrating the traditional graph tracing method.


Don?t you find it interesting that one of the most important steps in designing most antennas requires a pencil, ruler and often a magnifying glass in order to obtain the correct values to use in design algorithms? Living in the year 2010 (and not in the years ?before television?) one would think that the method of reading-off graph data from a published IEEE paper should have developed to be at least digitized. But most people still use the same old pencil and ruler method and then have to approximate the value which for some reason always lies on the steepest gradient of the graph resulting in high margin for error.

One of our engineers wrote a very handy Matlab tool which allows you to import a graph as a jpeg image and records the coordinates when clicking on the trace with your mouse, interpolating the X ? Y data, so it saves you the effort of printing the graph and reading off the values by hand. If you think you can use this tool drop me an email and I?ll send it to you.

Such a tool would probably be a very handy feature in Antenna Magus?watch this space.

Author: Robert Kellerman

Announcement: Antenna Magus Version 2.1 released

Tuesday, June 1st, 2010

A few weeks ago we announced our second major release, Version 2.0 which attracted world wide attention and we received overwhelmingly positive feedback. For those who missed the press release, you can find it here. We recently released version 2.1 which includes 6 new antennas in the database and some great new features. Read more bout Version 2.1 in Newsletter 2.1.

Preview of Newsletter 2.1

Preview of Newsletter 2.1

Author: Robert Kellerman

70% of published papers are a waste of time.

Thursday, May 27th, 2010

Most published antenna related articles are a waste of time when it comes to verifying the findings. When confronted with an unfamiliar antenna the first step is to find reliable published research and the problem is not finding papers. It’s like doing a Google search with a popular key phrase and trying to get the information you’re actually looking for. I remember a while ago one of our engineers was struggling with an antenna and in desperation he cried out and threw his hands in the air. Immediately the Marketing guy (that being me) said, “why don’t you just use Antenna Magus?”. Everyone in the office burst out laughing because he was busy working on a new antenna that still needed to be implemented.

Very few articles contain sufficient information in order to reproduce new findings. Surprisingly these are all papers that have been peer reviewed (sort of like an engineering stamp of approval) but most of them lack critical information like a physical parameter or material property or measurement distance. I’ve often wondered if it’s due to the authors negligence or is it done on purpose?

Here’s an example of an excellent reference article found by one of our engineers while implementing the Rectangular Capacitive-disc-fed Patch (which should be in version 2.1) G. Mayhew-Ridgers, J.W. Odendaal, and J. Joubert, “Efficient full-wave modeling of patch antenna arrays with new single-layer capacitive feed probes,” IEEE Transactions on Antennas and Propagation, Vol 53, No. 10, 2005, pp. 3219-3228.

It took him 10 minutes to figure out how to design and model the reference antenna design and reproduced the results in less than an hour.

Fortunately for our users Antenna Magus has all good published references listed in each antennas information document.

Looking for the needle in the haystack.

Looking for the needle in the haystack.

Author: Robert Kellerman

Story: How we added the Array synthesis tool in Antenna Magus (final: part3)

Friday, May 7th, 2010

In the previous two blog entries (part 1 and part 2) I showed two different prototypes of the array synthesis tool and summarised what we learnt from various user tests.

Just before we started to plan the third prototype we all sat around the table once again. Something was wrong, but I couldn’t quite put my finger on it.

It turns out that it is devilishly difficult to design an array while taking array element pattern into account. More importantly, the more elements you have, the less important the individual pattern becomes. Work that had been done quite a while before I had even started working at Magus included a design algorithm that designs arrays by assuming isotropic element patterns.

Furthermore, this is what antenna engineers also feel most comfortable with and why there was that unwillingness to start off with an element pattern each time.

Our terminology also had to be re-thought. “Array Calculator” became “Array Synthesis Tool” for the first time.

The three components: the array layout and excitation, element pattern and synthesized array were split up into three separate tabs.

Array tool: Final prototype (click to enlarge)

Array tool: Final prototype (click to enlarge)

Once again, a prototype was drawn up and put in front of five users (click on the image above to enlarge the final prototype). This time, we had a winner. The only biggish mental hurdle was apparent in users who had tried the previous prototypes and who now wondered, briefly, where their element pattern was coming from.

After tweaking a few last things, the array synthesis tool could be specified and implemented. Click here for a more detailed description and screen shots of the final array synthesis tool.

Author: Carien Fouch

Story: How we added the Array synthesis tool in Antenna Magus (part2)

Monday, May 3rd, 2010

I want to pick up the story on how we implemented the Array synthesis tool in Antenna Magus. The previous part1 of this blog series can be found here. In part1 I asked readers to look at the first prototype and to write down or comment on their first reactions.

This is what we learnt from the original usability tests:

  • The design confused people!
  • Fitting antenna parameters into the current Design Mode palette is a problem. Fitting array parameters into the palette would be impossible.
  • People don’t expect to be able to export a model of an array to a simulator. Most of the time, they are simply too big for full-wave analysis.

In the second design phase, we decided to go modal. The Array tool was separated from Magus’s Design Mode. One of the reasons for this was the sheer amount of information associated with arrays that had to be visible to the user. Another reason that emerged, after much discussion, was this: “Magus would not be taking mutual coupling into account.” By keeping the array calculator separate, we would not create that expectation. Parameters would be displayed in a large table in the main workspace, instead of trying to squeeze them in on the side-palette.

However, users would still start off by specifying an elemental pattern or dragging a pre-designed pattern of an antenna into the Array tool. After this, the excitation distribution and positions of elements, or some other objectives could be specified.

Array tool: Prototype 2 (click to enlarge)

Array tool: Prototype 2 (click to enlarge)

The prototype was drawn up in Balsamiq and five more users were tested.

This time, the usability tests went much more smoothly, however:

  • Users (as we expected) had trouble finding the array calculator
  • They seemed unwilling to start off with an element pattern
  • One tester began explaining the intricacies of measuring array S-parameter matrices to me and the difficulties of matching impedances. When I told him that this would not be taken into account by Magus, he said: “But this is useless!” It’s just a starting point!? Which is when he realised the intended value of the array calculator.
  • The design still felt a bit flaky, somehow.

Before designing the third prototype, we all sat around the table once again. Something was wrong, but I couldn’t quite put my finger on it.

In the 3d (last) part of this blog series, I will explain what final changes were made to the above prototype before we implemented the Array tool. Have a look at the above prototype so long (click to enlarge) and write down (or comment) what you think needed to change.

Author: Carien Fouch

Story: How we added the Array synthesis tool in Antenna Magus (part1)

Friday, April 9th, 2010

I’m currently reading a brilliant book called Sketching the User Experience (by Bill Buxton). It contains this quote: “The things we have to know before we do something, we learn by doing it.” This is certainly true of our experience designing the Array Synthesis Tool.

Sometime in early in 2009, we all sat around the table and decided that we would be including an array calculator in Magus, because people kept on asking us: Can Magus do arrays? So it seemed like a feature that a lot of people really needed.

But what does that mean? When people ask whether Magus does arrays, what exactly is it supposed to do?

To find out, we interviewed people at the coffee machine, over lunch and more formally in the boardroom. We asked questions like: What are common arrays? Why would you want one? How could Magus help you? If we told you that Magus now included an array calculator, what do you think it would do? Where do you start when you design an array?

Everyone had different answers. Nobody could tell us what they wanted specifically, but at least we could form an idea of the kinds of things that engineers thought about when thinking of arrays.

Magus had always included some basic arrays as antennas like the LPDA, the Yagi, little 2-by-2 patch arrays and later on the slotted waveguide array and our beloved braairooster antenna. But of course, these antennas have specific shapes and parameters.

Array antennas in the Magus database

Array antennas in the Magus database

An array calculator, on the other hand, would have to allow you to specify (almost) any number of radiators in different layouts and then tell you what the overall performance is.

With our first design we started off with the following two premises:

  • anything is possible and
  • an array is a bunch of antennas

To design an array, therefore, you first need to know what your elemental antenna looks like. After that you can decide how many you want and how they should be laid out.

In many ways, arrays are just like antennas. Hence we thought it would be great to incorporate the array design workflow into the existing antenna design workflow, in other words: make arrays work just like antennas.

The user would design an elemental antenna, like a patch or a dipole. He could then choose to make an array of it, either by specifying the number of elements in the x- and y-directions or allowing Magus to tell him the number of elements needed, their positions and their excitations.

The first prototype (shown in the image below) was drawn up in Balsamiq and put in front of five users. In the next blog I will write on what the usability tests told us but have a look at the prototype so long and write down (or comment) what you thought about it. Click on the image below to enlarge.

Array tool: Prototype 1 (click to enlarge)

Array tool: Prototype 1 (click to enlarge)

Author: Carien Fouch

Interview with Dan the validation man

Wednesday, November 18th, 2009
Interview between Dan and Robert

Interview between Dan and Robert


Of course the antenna design algorithms have to be validated! That’s what you’d expect from any good software?


Isn’t antenna design routine validation and model validation the same thing??

After hearing these comments I decided to move the spotlight onto Dan your validation man to see what validation is all about. He is the person charged with the job of ensuring that the algorithms used for antenna designs and antenna models that are exported from Antenna Magus are validated and can be trusted.

My chat with Dan went something like this:

Me: Hello Dan, I heard a lot of positive feedback from our users that they love the fact that the exported simulation models are ready to run. Can you please explain how you do it?

Dan: It is always great when we get positive feedback, but I definitely can’t take all the credit. It is a team effort between the engineers and myself.

Me: Some people think model validation and design routine validation is the same thing. Can you explain the differences?

(more…)

Roasting coffee at the office.

Thursday, November 5th, 2009

If you do not like to drink coffee the reason is you haven?t tasted good coffee? well that?s what happened to me at least. I never liked coffee and now I love it! The secret can be summed up in two words: ?freshly roasted?.

A couple of us at Antenna Magus take coffee quite seriously and this number is growing. This week one of our antenna engineers brought his ?coffee roaster? to the office and we photographed the roasting process as seen in the picture below.

The coffee roasting process.jpg

The coffee roasting process

This was actually done using a hot-air popcorn popper ? like the one here (which costs +- R 150/ $20 US). If you like coffee and want to give this a try, you have to do the following:

  1. Buy green coffee beans. Don?t just settle for anything -the best coffee comes from Africa (specifically Ethiopia and Kenya). Hawaii also has good coffee but it is overpriced and some Mexican coffee is also very good. These are all Arabica coffees which we prefer, but you may disagree as taste is a matter of personal opinion.
  2. Take a handful of green beans and pour them into the roaster. You get different types of roasters (or poppers as non coffee roasters like to call them) so the best way to determine the amount of beans you can roast at a time is to switch on the popper and slowly add more beans till just before they stop moving or rotating. If there are too many beans in the popper, the beans at the bottom will be burnt before those on top have even started roasting ? and your coffee will be terrible!
  3. Watch the beans as they start changing colour from green to light brown. As the beans begin to roast, they expand and become lighter and will start spinning more vigorously until they start hopping and jumping and small pieces of husk (we like to call it chaff) will start blowing off. Some people use a coke can with open ends to extend the hole of the roaster ? this stops the beans from escaping when they expand and over-fill the popper bowl.
  4. By now you should hear a cracking sound ? the beans have reached ?first crack? stage and have expanded to 130% of their original size. This should happen after 3 ? 6 minutes depending on the roaster?s wattage, ambient temperature and type of bean.
  5. ?The next stage is ?second crack? which usually happens about 2 ? 3 minutes after ?first crack?. The cracking noises at this stage are slightly less pronounced than the ?first crack?, and this is where you have to be very careful not to burn the beans. Depending on how dark you prefer the roast you can stop roasting just before ?second crack? for a lighter roast up to about 30 seconds after ?second crack? has started for a very dark roast. I usually stop 10 seconds after the start on ?second crack?.
  6. The final step is to cool down the roasted beans as quick as you can. The interesting thing here is that from somewhere around the ?second crack? stage, the roasting becomes exothermic, and will keep going even after the heat is removed. If you don?t cool down the beans quick they might start to smoke and get burnt. The best way to do this is to put the beans into a big metal container that will disperse the heat, and fan them for a short while to cool them down – I use a big old cooking pot, but any metal bowl or pan should also work.?

I recommend roasting outside, where the chaff will not cause a mess and remember to make sure that there are not too many people close by as they WILL harass you for some of your coffee once they?ve smelled the aroma of the fresh roast filling the air.

Flavor peak is 12 ? 48 hours after roasting but it still tastes very good immediately after roast. We use a second hand Nouva Simonelli industrial espresso machine at work (purchased from an out-of business restaurant that regularly has to be repaired – but that?s a different story on its own!)

So what has this got to do with antenna design? Nothing! I guess fresh roasted coffee is great, just like Antenna Magus!


Author: Robert Kellerman

arimidex online