Memory Management

[HB9LFU]

Hello mcHF programmers

has anybody thought of implementing memory banks for the mcHF rig?

Could they be managed via an external usb keyboard?

vy73s Roger

[df8oe]

Yes - this is already on our "2do-list". This idea was the reason to add serial EEPROM. I want to dd memory banks where you can name memories, import memories via USB-stick & textfile and so on. Will be implemented in future.

vy 73 Andreas

[HB9LFU]

Hello Andreas,

then it was a good idea to use serial EEPROMs in my mcHFs. Sounds very promising! Thanks!

vy73s Roger

[db4ple]

Getting support for anything externally connected to the USB is a problem right now, as we do not seem to be able to get the "big" USB connector working software wise. An alternative would be the use of a touch screen keyboard. Not as convenient but at least better under our control right know (but there is no touch keyboard yet and nothing related to memories to be honest, except for the some rather dead code).

[HB9LFU]

Does that mean that the "big" USB connector is useless and cannot be activated for anything helpful?

vy73s Roger

[db4ple]

At the momement yes. But this is as far as we can see, it is a software only issue. So there is hope. Both connectors are connected to different USB controllers inside the STM32F4. In theory, it is very easy to switch but in practice, it does not work yet. Once solved, many interesting options will be available how to use this second USB port.

[HB9LFU]

Ok, now that sounds more optimistic!

Maybe one can find information on addressing the usb controllers from other projects using the same processor ! ?

[df8oe]

No chance. I have dug the web many hours but no code example which uses the HS USB core in FS mode (thats the mode we need)was to find :(

vy73 Andreas

[HB9LFU]

Hello Andreas, on page 100 and following there is information about these controllers in different modes: http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/CD00289278.pdf

vy73s Roger

[df8oe]

We know this and have acted like this but does not work.

vy 73 Andreas

[HB9LFU]

Hello Andreas,

I am sorry for that! When I find details anywhere I will let you have a look at it.

vy73s Roger

[df8oe]

Very helpful would be a project which uses USB_HS core in FS mode. I have found nothing on the web - all projects included application notes from STM uses USB_FS core.

vy 73 Andreas

[HB9LFU]

http://comments.gmane.org/gmane.comp.lib.libopencm3/120

[db4ple]

Hi,

this example uses the OTG HS Embedded Phy (so far so good) in device mode. This is not what we want and need (we need the host mode). Device Mode -> Emulation of a USB device. This is how we connect the mcHF to the PC for USB Audio and CAT. Host Mode -> Allow USB devices (mouse, keyboard, ... ) to connect to us. We have host mode working for OTG FS controller but not for OTG HS controller

73 Danilo

On 11.04.2016 17:22, HB9LFU wrote:

http://comments.gmane.org/gmane.comp.lib.libopencm3/120

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/236#issuecomment-208399494

[HB9LFU]

Thanks Danilo for the explanation! Will look out for suitable project / code.

vy73s Roger

[HB9LFU]

Hallo Andreas, habe gerade den bootloader neu installiert. Ja, nun geht es auch mit der grossen USB-Buchse!! Gratuliere zu dem Durchbruch!!!

vy73s Roger

[phaethon]

Has the USB issue been solve since last comment as flash can be updated using large USB? Also, I have seen samples for USB at https://stm32f4-discovery.net/2014/05/all-stm32f429-libraries-at-one-place/ It uses HAL, but if it works, possibly, could be ported to StdPeriph

[db4ple]

Yes, sort of. We now know how to correctly handle the other USB controller, hence bootloader now can use the large USB. However, due to many other things we did not progress much on the memory issue itself but it gets higher priority now.

73 Danilo

[phaethon]

OK, moving with #9 then becomes more practical, too. Is the bootloader code the right place to see USB handling sample?

[f4fhh]

Hi

I was thinking to help on the subject of memory management. In discussion #870 we said that some changes in the structure that hold the transceiver state are probably needed but we must agree before on what is a "memory channel" and what is its content.

On my fellow FT-817, a memory channel is:

• a RX frequency
• a TX frequency (for split operations)
• the modulation mode (USB, LSB, CW...)
• the tuning step
• the filter settings
• the attenuator/preamp setting
• the RIT offset
• some settings related to VHF/UHF operations (DCS, CTSS, RPT...)
• an 8 character tag

All of these are squeezed in 26 bytes for each memory channel. That allows to store 200 channels in the 8k bytes eeprom of the 817.

It raises some questions:

• what to store in a memory channel ? all of the above + AGC settings ? a 16 character tag ?
• how many memory channels ? 10 banks of 20 channels ?
• what is the size of the eeprom ? 128kB ?
• must we insure compatibility with the 817 clone protocol ? chirp tool and others ?

Calling for ideas !

73 de Nicolas F4FHH

[df8oe]

Hi Nicolas,

I think we shall store as much as possible and add some spare bytes for later additions. For crawling through the memories it is a god idea to have memory places with a concrete length. I am not sure squeezing is a good idea. This has not high priority on our recent 2do-list - but I can give you some input:

You have to store character tag 16 bytes frequency VFO-A 4 bytes frequancy VFO-B 4 bytes

...and for each VFO mode 1 byte filter 1 byte tuning step 1 byte rx audio level 1 byte bas 1 byte treble 1 byte agc level 1 byte agc wdsp mode 1 byte agc wdsp slope 1 byte agc wdsp decay 1 byte agc threshold 1 byte agc hang enable 1 byte agc hang time 1 byte agc hang threshold 1 byte agc hang decay 1 byte tx power 1 byte tx audio compress 1 byte mic level 1 byte audio source 1 byte waterfall/spectrum 1 byte wf/spectrum magnify state 1 byte

Compatibility to any other rig is not possible. Implementation to chirp should not be a big problem at all and has lower priority than implementing memory places...

In virtual EEPROM we do have 16KB. These 16KB are included other configs which are stored. At the moment we only use ~400 Bytes so I think we can start with memory places at 2K.

In serial EEPROM we do have 128KB. So we must discuss if we detect what EEPROM is used and if we offer more places for serial EEPROM users.

There is many stuff to think over. At the moment we are busy in porting the code to our I40-SDR PCB which works witn a STM32F7 and has much more GPIOs and more hardware support (e.g. two seperate audio codecs). The second place where we are working is to implement good NB - and possibly NR. And we are thinking about restructuring audio filtering and demodulating path to a better working solution.

So much less time to think about memory places...

vy 73 Andreas

[f4fhh]

So 64 bytes is not enough for a memory place, The 24lc1025 has 128 bytes write buffers, I guess that 128 bytes is a good value for performance and alignment reasons. It leaves plenty of space for future extensions. Let's say 128 bytes for a memory place and 200 memories using ~26 kbytes. Do you think that we have to adjust the number of memories depending on the eeprom size ? Are 200 memories enough ? On my desktop IC-7000 I barely use 50 memory channels of the available 500....

[df8oe]

I agree that 128 bytes is a very secure value. For my opinion 200 places are absolutely enough - but let us listen to other statements...

Because of memory limitations at virtual EEPROM we must dynamically limit the maximum number of places for virtual EEPROM users. Serial EEPROMS are supported for >= 32KBytes size so no problem at all.

[f4fhh]

Is it better to allocate memories starting from 0x800 in the eeprom up to the end, or alternately, starting from the end and proceeding back to 0x800 ? Assuming that 0x800 is enough for all future settings extensions

As we have 128 byte per memory place, we also have the space in each memory for some kind of checksum and versionning to validate it. It could prevent nasty problems with eeprom corruption or clearing or firmware changes.

[db4ple]

I don't think, a fixed memory number will be a good idea. Some I2C EEPROMS are smaller than others, others are bigger (we have a range from 32k to 256k we support). It should be based on the available size. Working from the end or from the beginning makes no difference too me. FYI, currently we use about 800 bytes (not 400, that is the number of 16bit settings).

The current virtual eeprom (.aka flash) is completely different and cannot be easily split. Reason is a) the implentation we are using, uses the full 16k page to store its data. Reason is how flash works: a page (in this case 16k) can be deleted only at once and then written once in each location. So a fixed memory record location could be changed only once. A fixed 128byte memory location with lots of unused space would fill up the available flash memory more quickly than an approach which save memory records with exactly the necessary length. Once filled up an erase cycle is required to clear the page for further use (the data is of course copied to the second page before erase...) On the other hand, reading flash is compared to I2C very fast.

So for now my opionion is:

• No memory storage in flash memory, except for the "band memories" as we have them today.
• Flexible number of max memories in I2C, based on size. With 16k max allocation (good for 32k I2C) and 128 byte we would start with 128 memories, not too bad. Larger EEPROM can get more.
• Having a memory header which tells us some meta data about the memory record storage is good.
• Record based checksums are also good given the fact that we may have power interrupts at any time.
• For the same reason: each record should contain a record structure version number of its own, if a conversion to new structure is interrupted (we then can do a lazy conversion: only done if entry is changed).
• I am not sure, but I think we could discuss to have single VFO and split mode VFO memory.

[df8oe]

I have thought about different memory places (using one or both VFOs) already. My conclusion is not to offer two different storage systems (and handle two). Migration from a "simple" to a "full" memory place is complicated. There are multiple reasons why the use of both VFOs can be very helpful (for amateur radio and BC SWL use). So I think we shall start using ONE structure, which is future orientated. With 128 we are on the right track - I think. And 128 places would be enough for starting.

[db4ple]

Hi Andreas, you missunderstood: I did not mean to start with simple vs. full, I meant to record for a memory if it contains a single or split/dual VFO dataset so that you can select one memory for the currently active VFO (if single) or to A+B (split or dual). I think some will not like the fact that always the other VFO would be overwritten if a memory is changed.

[df8oe]

Hi Danilo,

yes I misunderstood. That was because of I never mentioned this way of using memories.... For me there are two "modes": "manual use" or "memory use". There is one button where you can change between this two modes. If you change from manual to VFO the last settings are buffered and not lost. With one button press you are back to manual (VFO)-Mode so no need for using only one VFO in memory mode. So you have to buffer the settings when entering memory mode. If you enter meory mode data from EEPROM is used. If you change something slightly (e.g. frequency, filter bw etc.) screen shows that you have changed something. You can decide to store this permanently or use it only temporarily. Many SWLs use both VFOs and set demodultaion of same radio station to different settings (AM, SAM, different filters...) to fast compare these two. The standard way of using memories is switching between memory mode and standard mode.

[f4fhh]

Hi all

Inspired by the 817, I was thinking to this memory model:

The radio could be tuned from 4 sources : VFOA, VFOB, MTUNE and MEMORY. Each source has its own mode/filter/agc settings. An index gives the primary source which both tunes the radio and can be modified by the user interaction with the UI. All other 3 sources are on standby.

You can switch the primary source from VFOA to VFOB and vice-versa with the VFO button. You can switch to the MEMORY source by pressing and holding the SPLIT button (it is then labelled MEM). When in memory mode you can switch to the MTUNE source by moving the TUNE encoder or changing any mode/filter/agc setting. From the MTUNE source you can go back to the VFO sources by pressing and holding the MEM button (it changes back to SPLIT). The MTUNE could also be stored in a MEMORY or transfered to a VFO

When the source is MEMORY or MTUNE, the split operation is implemented as a independent TX frequency stored in the MEMORY. The TX mode (AM/SSB/etc) is common with the RX. The MTUNE and MEMORY sources are similar to a VFO with the addition of a split TX frequency.

The UI integrates already the code that manages the function of the VFO button and that switches off the scope/waterfall to free the space for a memory list.

Is a memory model with this simple split mode enough for most uses ?

73 de Nicolas F4FHH

[df8oe]

Hi Nicolas,

sadly I think NO.

We have had many suggestions about memory capabilities and I am sure if we release such a simple structure there will come up many, many additional wishes and discussions. So storing both VFOs included all related settings (Filter, Mode, AGC etc.) is a MUST. So SWLs want to store different demodulation mode (AM / SAM) for getting best result in reception at each hour of the day only by changing VFOs in memory mode so a complete setting must be stored. And there are much more reasons why many users want to have two sets stored at each memory place... This cannot be solved to create multiple memory places because they want to change the settings very quick for better comparison. It would be difficult to relize that. You have to add resorting of the memories (which will be added in the future but we do not want to dig into this too deep at the moment).

73 de Andreas, DF8OE

[f4fhh]

Ok I understand the needs. Is there a commercial rig that implement memories like that ? None of my own transceivers (ft817 & ic7k) have double VFO memory channels. I must have a look on the usermanuals of the high end rigs.

[df8oe]

There is no commercial rig that works like that. But mcHF already does have some features no commercial rig offers - so nothing to care about ;) Our goal is to implement as much as possible users want to have. And editing this settings via USB later is not as complicate if we can export / import it as a simple configuration text file (like a config file under Linux).

[f4fhh]

So we have invent a new paradigm for memory channels...

What is left for the UI ? The SPLIT button is the entry point to the memory mode. We have the VFO button that we can repurpose to MEM WRITE for exemple. Are the TUNE and METER buttons absolutly needed ? Perhaps, the first task before anything is to find a way to maximise the usability of the 5 function keys.

[df8oe]

Sometimes I do have this, too. It is not reproduceable at all and the reason may be timing problems in mcHF (because of audio interrups). I can live without any problems with that and do not have investigated anything. It's ok for me.

[db4ple]

Regarding the 5 Buttons -> I recommend to read the Operating Menu to see how we utilize them today. Each button has 2 events we can detect right now:

• Short Press
• Press and Hold

There is already a MEM button function (w/o function) and the Meter button has back and forth (since we had previously SNAP allocate as primary function to the Meter button. Without much problems we can have at least one button event. But I think, and that is the reason why it takes so long, is to define a proper user interaction for memories. Storing and recalling is not a big deal. Knowing what to store is difficult but know how to interface all of this to the user is the real challlenge given the fact that we have a very small screen and no dedicated buttons for the memory yet. I propose to go to the wiki and to start defining/collecting some task / scenarios how the user will interact with the mcHF (e.g. "With an memory active, change to next memory", "Change tune frequency when a memory is active" ).

From this we could try to define what buttons / UI elements are required to implement these scenarios. To be clear: I propose the idea to work this way, I did not say I will lead the work. I don't think, the comment column in Github is the proper place to collect this information.