Asynchronous food material recording, custom dish generation calibration method and linkage system

Abstract

The application discloses an asynchronous food material recording and self-defined dish generation calibration method and a linkage system, breaks the traditional strong synchronous food material binding logic, completely decouples the weight collection and the food material identification matching time sequence, supports cross-period multi-food material rapid weighing and temporary recording, can combine multiple independent temporary entries into a self-defined dish, adds multiple switchable weight attribute tags such as fresh weight, cooked weight and share, directly reuses dish total nutrition data in the configuration process, avoids multiple nutrition data conflicts, matches the cross-end bidirectional synchronization mechanism of the electronic equipment and the mobile terminal, realizes data backup for each other, the whole machine standby power consumption is less than or equal to 10 mu A, the search response time is less than or equal to 300 ms, the error of the per-portion nutrition calculation is less than 3%, and the Chinese cooking scene and the fine nutrition management demand are greatly adapted.

Description

Technical Field

[0001] This invention relates to the field of intelligent weighing instruments and nutrition recording technology, and in particular to an asynchronous food recording, customized dish generation and calibration method and linkage system. Background Technology

[0002] Currently, the food recording logic in mainstream smart kitchen scales and related health apps generally adopts a strongly synchronous binding logic: "first select the matching standard ingredients in the built-in database, then place the ingredients and weigh them." After each food weighing, the system forces the user to confirm the name of the standard ingredients on the spot; otherwise, the next weighing process cannot proceed. This mode is usable for weighing a single type of ingredient, but in batch operations where 3-5 or even more ingredients need to be weighed for a meal, users need to repeatedly switch back and forth between the "select ingredients - place ingredients and weigh - confirm and save" interface. The food recording time for a single meal often exceeds 2 minutes. The operation steps are cumbersome, interrupt the cooking rhythm, and are completely unsuitable for the high-frequency operation needs in the kitchen.

[0003] Meanwhile, with the popularization of refined dietary management such as fat loss, muscle gain, and blood sugar control, people are increasingly keen on making their own healthy meals and home-cooked dishes, as well as other non-standardized pre-packaged foods. However, existing solutions do not have a mature mechanism for quickly generating custom recipes: every time a user eats homemade food and wants to record the total nutritional intake, they need to manually enter the name of each ingredient one by one and then estimate the weight of each ingredient based on experience. They cannot directly obtain the accurate nutritional value of the corresponding portion based on the saved custom recipes. Not only is the operation efficiency extremely low, but the weight error of manual estimation will also cause the final recorded nutritional data to deviate by more than 30%, completely losing the reference value of refined dietary management.

[0004] In addition, the traditional strong synchronization binding logic has two unresolved problems: First, if the wrong ingredient is selected after weighing, the ingredient must be re-placed and weighed again to correct the binding relationship, which can easily lead to record misalignment problems caused by the ingredients having already been processed and unable to be re-weighed; Second, in kitchen scenarios with poor network signal or when the mobile phone is temporarily not nearby, the ingredient matching operation cannot be completed, directly interrupting the entire weighing process, resulting in extremely poor adaptability.

[0005] Furthermore, existing smart kitchen scales often employ a "master-slave overwrite" mechanism for cross-device synchronization. Modifying ingredient records on the mobile app directly overwrites the original weighing data stored locally on the scale. If a record is accidentally deleted on the mobile app, the original weighing data on the scale is also erased, making it impossible to trace the original weight of the ingredients and rendering nutritional record traceability completely ineffective. Current mainstream health apps' custom recipe functions only support manual input of ingredient weights and cannot directly connect to real-time weighing data from the weighing sensor. Users must manually estimate the portion size each time they use homemade dishes, resulting in nutritional data errors generally exceeding 30%, which is completely unacceptable for people aiming to gain muscle and lose fat, requiring precise calorie control down to the gram. During Chinese cooking, users' hands are typically wet and oily, leading to a mis-touch rate exceeding 60% when inputting ingredient names on the scale's small touchscreen, resulting in a poor user experience. Existing solutions have consistently failed to resolve the cross-device division of labor and adaptation issue of "weighing hardware handling weighing and mobile terminals handling complex inputs." Summary of the Invention

[0006] Therefore, it is necessary to provide an asynchronous food recording, custom dish generation calibration method, and linkage system to address the aforementioned technical issues.

[0007] An asynchronous food recording method is applied to an electronic device equipped with a weighing sensor and a main control processing unit; The method includes the following steps: The electronic device responds to the start command and enters the asynchronous food recording mode; The system sequentially weighs X types of food ingredients to be tested and receives temporary naming instructions from the user, generating independent temporary food ingredient record entries, where X is a positive integer ≥ 2; Select any temporary food record entry and perform a food identifier binding operation. The main control processing unit calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and combines the weight information and corresponding nutritional parameters of the food to be tested to calculate and generate the actual nutritional data of the food and output it for display. The specific steps of sequentially weighing X types of food ingredients and receiving temporary naming instructions from the user are as follows: After any food ingredient is placed in the weighing area of ​​the electronic device, the electronic device performs a weighing operation, collects and obtains the weight information of the food ingredient; then the electronic device receives the corresponding temporary naming instruction input by the user, binds the temporary name with the collected weight information, and generates an independent temporary food ingredient record entry; the above operations are repeated.

[0008] In the aforementioned asynchronous ingredient recording method, the "asynchronous ingredient recording mode" specifically refers to breaking away from the traditional strongly synchronous binding sequence of "first selecting a standard food identifier in the database and then performing weighing." It completely decouples the two operation steps of "weight acquisition" and "ingredient identifier matching" in the time dimension. Users can first complete the weighing and temporary naming of all (or some) ingredients in one go, and then complete the batch binding of ingredient identifiers at any subsequent time point. The two operations do not need to be completed synchronously in the same scenario. In this mode, the temporary name entered by the user does not need to be pre-matched with the standard food identifier in the database; it is only used as a note label for that temporary record and is directly bound to the already acquired weight information to generate an editable, independent temporary ingredient record entry. This achieves rapid weighing and temporary recording functions during the cooking process, reducing the time spent on ingredient weighing during cooking. This method allows users to quickly weigh and temporarily store all (or some) ingredients first, and then bind them to the preset or stored food identifiers in the database in batches after cooking. The operation path of a single ingredient during cooking is compressed from the original "search food database → confirm matching standard food identifier → put ingredient to weigh" to "put ingredient to weigh → temporarily name". The operation steps and time of a single ingredient during cooking are greatly reduced. There is no need to repeatedly jump to the ingredient database search interface when weighing multiple ingredients. The efficiency of the entire process of weighing ingredients for making complex dishes is improved by more than 3 times. It is highly compatible with the operation habit of processing multiple ingredients in steps in Chinese cooking scenarios and will not interrupt the normal preparation and cooking rhythm.

[0009] In one embodiment, the steps of weighing X kinds of food ingredients to be tested and receiving temporary naming instructions from the user are repeated. The weighing and temporary naming of all food ingredients to be tested can be completed in multiple time periods, and at least two independent temporary food ingredient record entries are generated in the end.

[0010] In one embodiment, when the weight of the food to be measured is lower than a preset minimum weighing threshold, the electronic device automatically triggers a pop-up prompt and does not generate invalid temporary food record entries, thus avoiding the occupation of database storage space by invalid data of zero or very low weight. This preset minimum weighing threshold can be customized according to the range and accuracy of the weighing sensor. For example, for a kitchen scale with a range of 5kg and an accuracy of 1g, the threshold is set to 2g by default. Weights below this value are judged as invalid weight data generated by residual debris on the scale surface or accidental touch.

[0011] In one embodiment, when a user-inputted temporary name conflicts with an existing food identifier in the database, the main control processing unit automatically adds a unique suffix identifier to the newly generated temporary food record entry and generates an independent storage mapping path for the new entry. This unique suffix identifier uses a combination of a timestamp and a random checksum. For example, if the user inputs "tomato scrambled eggs" twice as a temporary name, the second generated entry will automatically be named "tomato scrambled eggs_20260822_7291," thus preventing name duplication issues from the outset.

[0012] In one embodiment, the main control processing unit receives a custom dish generation instruction, combines at least two independent temporary ingredient record entries into a complete custom dish, and generates a custom dish identifier. The triggering sequence of the custom dish generation operation can be configured to execute after some ingredients have been weighed and temporarily named, or after all ingredients have been weighed and temporarily named, or it can be configured to execute after some temporary ingredient record entries have been bound to food identifiers, or after all temporary ingredient record entries have been bound to food identifiers. After the custom dish is generated, it can be configured to either perform a storage operation based on user selection, storing the custom dish identifier in the database, or exit the current custom dish generation process directly without performing a storage operation.

[0013] In one embodiment, in response to adding, deleting or adjusting the quantity of ingredients in a custom dish that has already been generated, incremental nutrition calculation is performed only on the single target ingredient item that has been modified, while the original pre-stored nutrition parameters of the unmodified ingredients are directly reused.

[0014] In one embodiment, the main control processing unit responds to the weight status modification command by adding at least one switchable weight attribute label to the generated custom dish and entering the corresponding value; during the process of adding and configuring the weight attribute label, the total nutritional data already stored for the custom dish is directly used.

[0015] In one embodiment, the newly added weight attribute label includes at least one of cooked weight and serving size. The initial default weight attribute label bound to the custom dish is raw weight. After the custom dish is cooked, the electronic device collects the total cooked weight of the dish through a weighing sensor, adds a cooked weight attribute label to the custom dish and binds the collected cooked weight value. The total nutritional data of the dish associated with the cooked weight attribute label is consistent with the total nutritional data corresponding to the raw weight of the custom dish. And / or, the custom dish is divided into multiple independent equal units. The number of servings input by the user is received, and the pre-stored total raw weight value of the custom dish is directly called to automatically calculate and generate a single serving base weight value. A serving size attribute label is added to the custom dish and bound to the calculated single serving weight value. The nutritional data corresponding to a single serving of ingredients is directly mapped and generated based on the serving size attribute label. The total nutritional data associated with the serving size attribute label is consistent with the total nutritional data corresponding to the raw weight of the custom dish.

[0016] The aforementioned weight attributes form a complete raw-cooked portion conversion system, solving the technical problem of chaotic nutritional conversion between raw and cooked weights in traditional solutions. For example, a serving of scrambled eggs with tomatoes that has a raw weight of 500g will have a cooked weight of 400g. When a user consumes 200g of the cooked portion, the system can directly and accurately calculate the nutritional data corresponding to that 200g portion based on the baseline value of the cooked weight attribute label, without requiring the user to manually calculate the raw-cooked conversion coefficient.

[0017] In one embodiment, the main control processing unit synchronizes the stored custom dish identifiers to third-party devices, enabling cross-device sharing of custom dish identifiers.

[0018] In one embodiment, the generated custom dish identifier can be exported as a separate data package containing total nutritional data and multiple sets of weight attribute labels. After importing this data package, third-party devices can directly reuse all the nutritional conversion logic of the custom dish. The separate data package is encapsulated in a lightweight JSON format and contains only three core data types: dish name, total nutritional parameters, and multiple sets of weight attribute values. It does not involve user privacy information and can be quickly shared through various methods such as QR code and Bluetooth transmission. It supports compatible import across smart weighing terminals and / or mobile terminals of different brands.

[0019] In one embodiment, the main control processing unit responds to the user's input search command, obtains the total nutritional data within the custom dish identifier, and outputs and displays it.

[0020] In one embodiment, the main control processing unit responds to the user's input search command by retrieving the baseline total nutrition data associated with the custom dish identifier, multiple sets of switchable weight attribute tags, and the corresponding dimension's nutrition mapping relationship, and outputs and displays the corresponding dimension's detailed nutrition data.

[0021] In one embodiment, the retrieval and ranking algorithm of the main control processing unit assigns the same retrieval weight to custom dish identifiers and system-preset standard food identifiers. Priority is given to matching entries with the highest user frequency in the past 7 days. Entries with a matching degree meeting a preset threshold are pushed to the interactive interface for user selection, with a retrieval response time of ≤300ms. Compared to the average retrieval speed of 1000ms for conventional smart kitchen scale apps, this represents an efficiency improvement of over 70%. This retrieval and ranking algorithm can be deployed locally on the electronic device or mobile terminal. Here, "matching degree meeting a preset threshold" specifically refers to the character similarity between the user-input search keywords and the food identifier name being higher than 80%. All entries meeting this condition are pushed in descending order of usage frequency, preventing a large number of irrelevant entries from occupying the interactive interface.

[0022] In one embodiment, when a user enters a temporary naming command, the system automatically matches a list of food identifier candidates with a similarity of ≥85% in the database, supporting one-click selection to complete the binding, without requiring the user to manually enter the complete ingredient name.

[0023] In one embodiment, the retrieval ranking algorithm incorporates a custom-defined weight factor for specific dishes. This weight factor has a higher priority than the weight of the system's preset standard food identifiers, ensuring that user-defined dishes are always ranked higher than standard food identifiers with the same matching degree. The default value of this custom weight factor can be set to 1.2. The ranking score of custom dishes with the same matching degree will be multiplied by this coefficient, ensuring that frequently used dishes created by the user are always ranked at the top of the search results.

[0024] In one embodiment, the main control processing unit responds to a weighing command. When a user weighs a custom dish, the electronic device can directly calculate the nutritional data of the corresponding portion based on the currently collected real-time weighing weight.

[0025] In one embodiment, the main control processing unit responds to the custom dish weighing command, identifies the target weight attribute dimension corresponding to the current weighing operation, directly retrieves the mapping relationship between the pre-stored total nutrition data and the corresponding weight attribute label under the custom dish identifier, and generates the corresponding portion of accurate nutrition data based on the currently collected real-time weighing weight and outputs and displays it.

[0026] In the aforementioned asynchronous ingredient recording method, the custom dish identifier stored in the database can be configured to be automatically included in the food identifier index library. The system automatically assigns a globally unique retrieval ID to it and synchronously completes the pre-calculation and persistent storage of the dish's total nutritional parameters. When a user initiates a retrieval operation in any new weighing process, the main control processing unit will push the custom dish identifier along with other food identifiers whose matching degree meets a preset threshold to the interactive interface for the user to directly select and call. This custom dish identifier is pre-bound to the complete nutritional data of the entire dish. When a user weighs this homemade dish, the system can directly calculate the accurate nutritional data value corresponding to the portion taken based on the current weighing value, without requiring the user to estimate the weight of each ingredient based on experience, or to re-perform identifier matching and nutritional conversion calculations for each individual ingredient. Simultaneously, this solution retains an optional entry point for manually triggering recalculation, allowing users to edit the ingredient composition of the dish as needed and refresh the total nutritional data of the custom dish.

[0027] The present invention also provides a method for generating custom dishes, which is applied to electronic devices equipped with weighing sensors and main control processing units; The method includes the following steps: The electronic device responds to the start command and enters the food weighing and recording mode; The main control processing unit receives the food input instruction, triggers the first input path or the second input path, and generates at least two independent food record entries. The first input path is an asynchronous food recording mode: the electronic device sequentially performs weighing operations on X kinds of food to be tested. After any food to be tested is placed in the weighing area of ​​the electronic device, the weight information of the food to be tested is collected. Then, the temporary naming instruction corresponding to the food to be tested is received by the user. The temporary naming instruction is bound to the collected weight information to generate an independent food record entry, where X is a positive integer ≥2. The above operation is repeated. The second input path is a pre-identification matching path: the electronic device first receives at least one food identifier selected by the user, then triggers a weighing operation to collect the weight information of the corresponding food to be tested, binds the selected food identifier with the corresponding collected weight information, and generates an independent food record entry. The main control processing unit receives a custom dish generation instruction, combines at least two independent ingredient record entries into a complete custom dish, and generates a custom dish identifier.

[0028] In one embodiment, the method for generating custom dishes further includes the steps of: selecting any temporary ingredient record entry generated by the first input path and performing a food identifier binding operation; the main control processing unit calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and, in conjunction with the weight information and corresponding nutritional parameters of the ingredient to be tested, calculates and generates the actual nutritional data of the ingredient and outputs and displays it.

[0029] In one embodiment, the main control processing unit responds to the weight status modification command by adding at least one switchable weight attribute label to the generated custom dish and entering the corresponding weight value or serving size value; during the process of adding and configuring the weight attribute label, the total nutritional data already stored for the custom dish is directly used.

[0030] In one embodiment, the newly added weight attribute label includes at least one of cooked weight and number of servings, and the weight attribute label initially bound to the custom dish by default is raw weight.

[0031] In one embodiment, the cooked weight state corresponds to the following operation scenario: after the custom dish is cooked, the electronic device collects the total cooked weight of the dish after cooking through a weighing sensor, adds a cooked weight attribute tag to the custom dish and binds the collected cooked weight value; the total nutritional data of the dish associated with the cooked weight attribute tag is consistent with the total nutrient data corresponding to the raw weight of the custom dish. The operation scenario corresponding to the number of servings is as follows: the custom dish is divided into multiple independent equal units, the number of servings input by the user is received, the pre-stored total raw weight value of the custom dish is directly called to automatically calculate and generate the base weight value of a single serving, a serving number attribute tag is added to the custom dish and the calculated single serving weight value is bound; based on the serving number attribute tag, the nutritional data corresponding to a single serving of ingredients is directly mapped and generated, and the total nutritional data associated with the serving number attribute tag is consistent with the total nutrient data corresponding to the raw weight of the custom dish.

[0032] In one embodiment, all steps of the custom dish generation method can be executed across terminals in a linkage system consisting of an electronic device configured with a weighing sensor and a mobile terminal: the food weighing operation is completed by the electronic device, while the temporary naming, food identifier matching, and custom dish combination generation operations are completed by the mobile terminal, and the weight information collected by weighing is transmitted to the mobile terminal in real time through a two-way synchronous link.

[0033] The aforementioned method for generating custom dishes adds two switchable weight attribute tags—cooked weight and serving size—to the raw weight, without altering the total nutritional data of the custom dishes. These tags correspond to the entire dietary process, from weighing after cooking to dividing the food into equal portions. This solves the pain points of traditional ingredient recording methods, such as cumbersome raw-cooked weight conversion and large errors in nutritional calculations for portioning. Users no longer need to manually and repeatedly adjust the total ingredient quantity; they can switch between different weight attributes with a single click and automatically complete the corresponding nutritional conversion. The nutritional data calculation error in portioning scenarios is reduced from over 15% in traditional methods to less than 3%, perfectly meeting the precise portioning needs of people aiming to build muscle and lose fat.

[0034] This invention also provides a customizable multi-state weight calibration method for dishes, applicable to electronic devices equipped with weighing sensors and main control processing units, comprising the following steps: In response to the completion command for generating a custom dish identifier, the main control processing unit configures at least two switchable weight attribute tags for the generated custom dish. And / or, in response to the weight status modification command, the main control processing unit adds at least one previously unconfigured switchable weight attribute label to the generated custom dish; The main control processing unit will calculate the single-serving weight value obtained by collecting or entering the weight value or the number of servings input by the user, and associate and store it with the selected target weight attribute label. During the binding configuration of the weight attribute label, the total nutritional data already stored for the custom dish will be directly used. The main control processing unit, based on the currently activated weight attribute and its corresponding bound weight value, calls the conversion mapping relationship between the stored total nutrient data and the baseline weight value corresponding to the currently activated weight attribute, generates the corresponding portion of nutrient data, and outputs and displays it.

[0035] In one embodiment, all steps of the custom dish multi-state weight calibration method can be executed across terminals in a linkage system consisting of an electronic device configured with a weighing sensor and a mobile terminal: the generation of custom dish identifiers, modification of weight status and nutritional conversion operations are completed by the mobile terminal, the acquisition of cooked weight values ​​is completed by the weighing sensor of the electronic device, and the acquired weight data is transmitted back to the mobile terminal in real time through a two-way synchronous link to complete the binding.

[0036] The aforementioned method for multi-state weight calibration of custom dishes dynamically calculates weight based on the ratio of total nutritional data to the activated weight attribute. This eliminates the need to store a complete set of nutritional parameters separately for each weight attribute, reducing redundant database storage and ensuring logical consistency in nutritional data conversion across different weight states. Even if more custom weight attributes are added later, there is no need to modify the original total nutritional data. The development cost of adapting the system to new weight attributes is reduced by 70%, while completely avoiding data conflicts and inconsistencies that can easily occur when multiple sets of nutritional data are stored in parallel.

[0037] This invention also provides an asynchronous cross-terminal linkage method for food recording, which is applied to a linkage system consisting of an electronic device equipped with a weighing sensor and a main control processing unit and a mobile terminal connected through a wireless communication link; The method includes the following steps: The mobile terminal responds to the start command and enters asynchronous food recording mode; X types of food ingredients to be tested are weighed sequentially and synchronized to the mobile terminal, where X is a positive integer ≥ 2; after any food ingredient to be tested is placed in the weighing area of ​​the electronic device, the electronic device performs a weighing operation, collects and obtains the weight information of the food ingredient to be tested, and pushes the weight information to the mobile terminal in real time; after the mobile terminal receives the weight information of any food ingredient to be tested, it receives the corresponding temporary naming instruction input by the user, binds the temporary name with the synchronized weight information, and generates an independent temporary food ingredient record entry; Select any temporary food ingredient record and perform a food identifier binding operation. The mobile terminal calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and combines the weight information and corresponding nutritional parameters of the food ingredient to be tested to calculate and generate the actual nutritional data of the food ingredient and output it for display.

[0038] In the above-described linkage method, the weighing operation is performed on X kinds of ingredients sequentially, and the corresponding temporary naming command input by the user is received. The weighing and temporary naming of all ingredients to be tested can be completed multiple times across time periods, ultimately generating at least two independent temporary ingredient record entries. The mobile terminal transmits the generated temporary ingredient record entries and nutritional data back to the local electronic device for data backup, achieving consistent updates of ingredient record data at both ends. In response to the start command, the mobile terminal can either enter the asynchronous ingredient recording mode of the mobile terminal or the asynchronous ingredient recording mode of the electronic device, using the mobile terminal's wireless communication function to remotely edit and configure parameters on the electronic device.

[0039] In one embodiment, in the above-described linkage method, the mobile terminal may also perform any one or more of the following operations: Receive a custom dish generation instruction, combine at least two independent temporary ingredient record entries that have completed food identifier binding into a complete custom dish, generate a custom dish identifier and store it in the local database; In response to the weight status modification command, at least one switchable weight attribute label that was not previously configured is added to the generated custom dish; the main control processing unit associates and stores the weight value of a single serving obtained by calculating the weight value collected or entered, or the number of servings entered by the user, with the selected target weight attribute label. During the binding configuration of the weight attribute label, the total nutritional data already stored for the custom dish is directly used; based on the currently active weight attribute and the corresponding bound weight value, the main control processing unit calls the conversion mapping relationship between the stored total nutritional data and the baseline weight value corresponding to the currently active weight attribute, generates the nutritional data of the corresponding portion, and outputs and displays it.

[0040] In one embodiment, the main control processing unit allocates a dedicated contiguous physical storage address segment for each newly created temporary food ingredient record. Subsequent additions to the food ingredient record are directly appended to the end of the corresponding address segment without overwriting previously stored historical food ingredient data. This storage mechanism is implemented based on Flash physical partitions, with each temporary food ingredient record allocated at least 4KB of contiguous dedicated address segment. Data writing follows an "append-without-overwrite" rule, ensuring that even if the device experiences an unexpected power outage, historical data already written to the address segment will not be erased, thus guaranteeing data reliability at the hardware level.

[0041] In one embodiment, the asynchronous ingredient recording mode supports temporary record retention for up to 72 hours. If the device loses power and is then powered on again, the stored temporary ingredient records will not be lost. Upon waking, new entries can be added directly to the existing, incomplete temporary records. The 72-hour retention period is suitable for the food preparation cycle of most households. Users can weigh all ingredients on the first night and then complete the ingredient identification binding after cooking the next day, completely unrestricted by time or scenario.

[0042] The aforementioned linkage method separates and links the precise weighing capability of electronic devices with the flexible naming capability of mobile terminals. It achieves sequential weighing and cross-device binding of multiple food items through asynchronous mode, coupled with a dedicated continuous physical storage address range and a temporary record retention mechanism for up to 72 hours. This solves the problems of small user interfaces and low efficiency of manual naming in traditional solutions, while also preventing data loss due to power outages or operation interruptions. The overall operation time for batch weighing multiple food items is reduced by 50% compared to completing the entire process with a single device, and the smoothness of operation in scenarios involving continuous weighing of multiple food items is significantly improved.

[0043] In one embodiment, when a user completes any of the following operations on the mobile terminal: editing a temporary food record entry, generating a custom dish, or adding a weight attribute label, the mobile terminal automatically backs up the edited food record data to the storage area of ​​an electronic device equipped with a weighing sensor, thereby achieving bidirectional consistency verification and backup of the food record data at both ends.

[0044] In one embodiment, when the communication link between the electronic device and the mobile terminal is interrupted, both ends cache the unsynchronized food record data. After the communication link is re-established, the interruption resume synchronization operation is automatically triggered, so there will be no problem of data loss or duplicate upload.

[0045] The present invention also provides an asynchronous food recording electronic device, comprising: A weighing sensor is used to collect the weight information of the food to be measured placed in the weighing area; The main control processing unit is used to enter the asynchronous food recording mode in response to the start command; The storage module is pre-stored with food identifiers and corresponding nutritional parameters. It is used to store temporary food record entries, generated custom dish identifiers, and nutritional mapping relationships of at least one of multiple sets of weight attribute labels. The main control processing unit is also used to perform any one or more of the following operations: The database is called to filter out at least one food identifier that corresponds to the temporary naming instruction. The weight information and corresponding nutritional parameters of the food to be tested are combined to calculate and generate the actual nutritional data of the food and output it for display. Receive a custom dish generation instruction, combine at least two independent temporary ingredient record entries into a complete custom dish, and generate a custom dish identifier; In response to the weight status modification command, at least one switchable weight attribute label that was not previously configured is added to the generated custom dish; the main control processing unit associates and stores the weight value of a single serving obtained by calculating the weight value collected or entered, or the number of servings entered by the user, with the selected target weight attribute label. During the binding configuration of the weight attribute label, the total nutritional data already stored for the custom dish is directly used; based on the currently active weight attribute and the corresponding bound weight value, the main control processing unit calls the conversion mapping relationship between the stored total nutritional data and the baseline weight value corresponding to the currently active weight attribute, generates the nutritional data of the corresponding portion, and outputs and displays it; By establishing data interaction with the mobile terminal through a preset two-way synchronization link, the collected weight information of the food to be tested is synchronized to the mobile terminal in real time, and / or the food record editing data returned by the mobile terminal is received to complete local consistency backup; the mobile terminal can independently perform operations such as entering asynchronous food recording mode in response to the start command, calling the database, inputting temporary names, matching and binding food identifiers, generating custom dishes, and modifying weight status.

[0046] In one embodiment, the electronic device, in asynchronous food recording mode, after collecting the weight information of the food to be tested, automatically locks the current weighing result and then receives the corresponding temporary naming instruction input by the user. After the user confirms that the naming information is accurate and triggers the save operation, the temporary name is bound to the corresponding weight information to generate a temporary food record entry, and the process of weighing the next food to be tested is directly started.

[0047] In one embodiment, in the above-mentioned electronic device, when the weight value of the food to be measured collected by the weighing sensor fluctuates less than a preset threshold within a preset time window, the weight is determined to be stable and the weighing result is locked. The main control processing unit is also used to perform any one or more of the following operations: The output pulse signal turns on the peripheral power supply circuit, wakes up the microphone module to receive the user's voice temporary naming command; When there is no valid voice command input, the power supply circuit is automatically disconnected to return the pickup module to the power-off state. In asynchronous food recording mode, when no food is detected in the weighing area, the main control processing unit automatically controls the whole machine to enter a low-power standby state with a standby power consumption of less than 10μA. After the food to be tested is placed, it will automatically wake up and enter the weighing process.

[0048] This invention also provides an asynchronous cross-platform food ingredient recording system, comprising: The device includes an electronic device and a mobile terminal configured with a weighing sensor and a main control processing unit, wherein the electronic device and the mobile terminal establish a two-way data synchronization connection through a wireless communication link. The electronic device is used to respond to the asynchronous mode trigger command issued by the mobile terminal to enter the asynchronous food recording mode, or to maintain the normal weighing standby state; to perform weighing operations on X kinds of food to be tested in sequence, where X is a positive integer ≥2; after any food to be tested is placed in the weighing area of ​​the electronic device, the weighing operation is performed to collect and obtain the weight information of the food to be tested, and the weight information is pushed to the mobile terminal in real time through the wireless communication link. The mobile terminal establishes a communication connection with the electronic device to respond to a start command and enter its own asynchronous food recording mode, and / or remotely triggers the electronic device to enter the asynchronous food recording mode via a wireless communication link, and performs remote parameter editing and configuration on the electronic device through wireless communication. After receiving the weight information of each food item to be tested, it receives a temporary naming command input by the user that corresponds one-to-one with the current food item to be tested, binds the temporary name to the synchronized weight information of that item, and generates at least two independent temporary food record entries locally. The weighing and temporary naming process of all food items to be tested can be completed in multiple time periods. The mobile terminal is also used to perform any one or more of the following operations: The database is accessed to filter out at least one food identifier corresponding to the temporary naming instruction. The weight information and corresponding nutritional parameters of the food to be tested are combined to calculate and generate the actual nutritional data of the food and output it for display. The generated temporary food record entries and nutritional data are backed up and synchronized to the local electronic device to complete the data backup, so as to achieve consistent updates of food record data at both ends. Receive a custom dish generation instruction, combine at least two independent temporary ingredient record entries into a complete custom dish, and generate a custom dish identifier; In response to a weight status modification command, at least one previously unconfigured switchable weight attribute label is added to the generated custom dish; the collected or entered weight value, or the single-serving weight value calculated from the user-input serving value, is associated and stored with the selected target weight attribute label; during the binding configuration of this weight attribute label, the total nutritional data already stored for the custom dish is directly used; based on the currently active weight attribute and the corresponding bound weight value, the conversion mapping relationship between the stored total nutritional data and the weight value corresponding to the currently active weight attribute is invoked to generate the nutritional data for the corresponding serving size and output it for display; A bidirectional synchronization link is configured in the wireless communication link between the electronic device and the mobile terminal. It is used to synchronize the weight information collected by the electronic device to the mobile terminal in real time, and / or receive the food record editing data returned by the mobile terminal and automatically synchronize and back it up to the local of the electronic device, so as to complete the consistency verification and retention of the data at both ends.

[0049] In one embodiment, the data synchronization between the electronic device and the mobile terminal adopts the MD5 checksum retransmission mechanism, reducing the data packet misalignment rate of cross-terminal synchronization to 0. The same electronic device supports binding multiple authorized mobile terminals. The main control processing unit allocates a dedicated continuous physical storage address segment for each bound terminal's newly created temporary food record entry. Temporary records from different terminals are allocated independent physical address segments in the electronic device's storage unit, eliminating the risk of cross-account data overwriting. When the communication link between the electronic device and the mobile terminal is interrupted, both ends cache the unsynchronized food record data. After the communication link is re-established, the interruption resume synchronization operation is automatically triggered, so there will be no data loss or duplicate upload. The asynchronous food recording mode supports temporary record retention for up to 72 hours. If the electronic device loses power and is powered on again, the stored temporary food records will not be lost. After waking up, new entries can be added directly on the basis of the original incomplete temporary records.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] This invention addresses the industry pain points of existing smart kitchen scales, such as strong synchronous binding of food recording processes, poor reusability of customized dishes, and easy disconnection in cross-device linkage. Based on the unified inventive concept of "asynchronous food recording + customized dishes + multi-dimensional weight management", it constructs a complete technical closed loop, from rapid weighing of single ingredients, temporary record solidification, standardized accumulation of customized dishes, to calibration of multiple weight attributes of raw and cooked foods, and cross-device two-way synchronous backup. It completely breaks the operation sequence limitations of traditional food recording solutions, greatly adapts to Chinese cooking scenarios and the needs of refined nutrition management, and has extremely high practical and promotional value in the field of smart kitchens for small home appliances.

[0052] Technical aspects of the effect: In asynchronous recording mode, the entire process of weighing multiple ingredients for a single meal is reduced from more than 2 minutes to less than 40 seconds, improving operational efficiency by 300%. Custom menu search response time is ≤300ms, which is 70% more efficient than the industry standard of 1000ms. Cross-device synchronization employs the MD5 hash verification mechanism, reducing the data packet misalignment rate to 0 and achieving an eventual consistency success rate of ≥99.9% between the two ends. The standby power consumption of the whole machine is ≤10μA, and the battery life is increased from the usual 7 days to 32 days, which is 357% more powerful.

[0053] Experience Dimension Effect: In the scenario of preparing Chinese food in bulk, the recording of ingredients does not interrupt the cooking rhythm at all. The voice input function solves the problem of accidental touch when hands are wet or oily during cooking, reducing the accidental touch rate from 60% to less than 5%. After multi-state calibration of custom dishes, the error in calculating nutritional data in the meal-sharing scenario has been reduced from more than 15% to less than 3%, fully meeting the daily calorie control needs of people who want to gain muscle and lose fat. Temporary records can be stored offline for up to 72 hours, with zero data loss in the event of power outages or network disconnections, adapting to asynchronous operation needs in multiple scenarios.

[0054] Commercial impact: Custom recipes support cross-device data package export and import, enabling users to create and share healthy meal recipes on social media, significantly enhancing user stickiness and social sharing attributes of smart scale products; The multi-terminal permission isolation mechanism is adapted to the scenario of multiple family members sharing the same device. A single device can support the independent and detailed nutrition recording needs of multiple people at the same time, greatly expanding the commercial application scope of the product. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of the asynchronous food recording electronic device of the present invention;

[0056] Figure 2 This is a schematic diagram of the hardware structure of the asynchronous food recording electronic device of the present invention;

[0057] Figure 3 This is a schematic diagram of the asynchronous food ingredient recording cross-terminal linkage system of the present invention;

[0058] Figure 4 This is the overall main flowchart of the asynchronous food recording method of the present invention;

[0059] Figure 5 This is the overall main flowchart of the custom dish generation method of the present invention;

[0060] Figure 6 This is the overall main flowchart of the custom dish multi-state weight calibration method of the present invention;

[0061] Figure 7 This is the overall main flowchart of the asynchronous food recording cross-terminal linkage method of the present invention.

[0062] Explanation of reference numerals in the attached diagram: 1. (Asynchronous food recording) electronic device; 11. Main control processing unit; 12. Weighing sensor; 13. Storage module; 14. Bluetooth module; 15. Sound pickup module; 16. Local offline voice recognition chip; 10. Panel; 20. Lens; 30. Front cover; 40. Weighing feet; 50. Bottom cover; 60. PCB board; 70. Microphone; 80. Touch button module; 90. Display module; 2. Mobile terminal. Detailed Implementation

[0063] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Preferred embodiments of the invention are shown in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a thorough and complete understanding of the disclosure of the invention.

[0064] It should be noted that when a component is said to be "fixed to" another component, it can be directly on the other component or there may be an intervening component. When a component is said to be "connected to" another component, it can be directly connected to the other component or there may be an intervening component.

[0065] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0066] Unless otherwise specified, all reagents used in the following examples are commercially available; and all methods used in the following examples are conventional methods. Terminology Definition

[0067] Asynchronous food recording mode: This refers to a non-sequential operation mode that completely decouples the two steps of food weight collection and food name selection, unlike the forced synchronous process of traditional smart kitchen scales that "first selects the standard food label in the database and then performs the weighing". It is not a multi-threaded asynchronous scheduling concept in the general field of computer science.

[0068] Temporary ingredient record entries: These are temporary records generated by the device before the standard ingredient matching is completed. The device directly binds the user-inputted custom temporary name and the collected original weight information to these records. The storage can be completed without verifying whether the name is in the system database, and it supports subsequent secondary editing and replacement matching.

[0069] Food labels include two types of searchable labels. One type is the standard food label pre-set by the system, which specifically refers to the labels of regular ingredients that have been pre-stored in the database when the equipment leaves the factory and have completed the corresponding nutritional parameter calibration. The other type is the user-defined dish label stored in the database, which is generated by the user during use. The two types of labels are scheduled using completely unified retrieval rules in the index library, and there is no difference in priority in the calling logic.

[0070] Peripheral scheduling core: This is an independent computing sub-core / external low-power coprocessor that is hardware isolated from the weighing calculation core. It independently handles basic detection tasks such as button operation, touch control, Bluetooth, and peripheral power supply on / off without interfering with high-precision weighing sampling, thus avoiding accuracy errors caused by peripheral interaction interruptions during the weighing sampling process.

[0071] Peripheral power supply circuit: This is a physical circuit unit at the hardware level. Its core function is to control the power supply of peripherals such as the pickup module 15 through pulse signal switching. It belongs to the category of pure hardware circuit.

[0072] Hardware trigger switch: A physical hardware unit that directly controls the power supply circuit based on physical level. It can achieve accurate triggering of peripherals without relying on software polling, completely cut off the standby power supply circuit of peripherals, and greatly reduce the standby power consumption of the whole machine.

[0073] Dedicated contiguous physical storage address segment: refers to the continuous and uninterrupted physical storage address space allocated by the main control processing unit 11 in the temporary cache sector for each independent dish index folder. Subsequent ingredient records are written to this contiguous address segment first, which can avoid addressing delay and data fragmentation caused by scattered address writing. Only when this contiguous address space is exhausted will other free sectors be scheduled to take over the overflow data.

[0074] Equal weight retrieval mode: This means that user-created dish entries in the permanent custom library sector and system-preset standard ingredient entries in the basic food library sector have the exact same weight coefficient in the retrieval and ranking algorithm. There is no system-built-in rule for priority ranking of entries, and the retrieval response speed and ranking priority are completely consistent.

[0075] Fuzzy matching operation: This is the operation logic of the main control unit to calculate the matching score based on three dimensions: first, the character overlap between the temporary name and the standard food name; second, the matching degree between the temporary name and the full pinyin / first letter of the standard food name; and third, the association mapping matching degree between the temporary name and the pre-stored ingredient aliases. The preset threshold for the operation is set to 80 points by default. Candidate food icons with scores higher than this value can be entered into the selectable drop-down list. This threshold can be customized and adjusted by users according to their own usage habits.

[0076] Multi-core independent sleep architecture: The weighing sampling core and the main control system core of this patented electronic device adopt an independent power supply design. When no food is placed, the weighing sampling core intermittently samples weight data at a low frequency of 1Hz, and the system core enters a deep sleep state. The standby power consumption of the whole machine can be controlled within 10μA. After the food to be tested is placed and the weight change threshold is triggered, the system core wakes up from the deep sleep state within 10ms and enters the full power weighing mode.

[0077] This application provides an asynchronous food recording electronic device 1, such as... Figure 1 and 2 As shown, it includes:

[0078] Weighing sensor 12 is used to collect the weight information of the food to be measured placed in the weighing area;

[0079] The main control processing unit 11 is used to enter the asynchronous food recording mode in response to the start command;

[0080] Flash storage module 13 is pre-stored with food identifiers and corresponding nutritional parameters. It is used to store temporary food record entries, generated custom dish identifiers, and nutritional mapping relationships of at least one of multiple sets of weight attribute labels.

[0081] The aforementioned main control processing unit 11 is also used to perform any one or more of the following operations:

[0082] (1) Call the database, filter out at least one food identifier corresponding to the temporary naming instruction, combine the weight information of the food to be tested with the corresponding nutritional parameters, calculate and generate the actual nutritional data of the food and output and display it.

[0083] (2) Receive custom dish generation instructions, combine at least two independent temporary ingredient record entries into a complete custom dish, and generate a custom dish identifier;

[0084] (3) In response to the weight status modification command, add at least one switchable weight attribute label that has not been configured before to the generated custom dish; the main control processing unit 11 associates and stores the weight value of the collected or entered weight value or the single weight value obtained by the user input of the number of portions with the selected target weight attribute label. In the process of binding and configuring the weight attribute label, the total nutritional data of the custom dish that has been stored is directly used; the main control processing unit 11 calls the conversion mapping relationship between the stored total nutritional data and the benchmark weight value corresponding to the currently activated weight attribute based on the currently activated weight attribute and the corresponding weight value, generates the nutritional data of the corresponding portion and outputs and displays it.

[0085] (4) Establish data interaction with mobile terminal 2 through a preset bidirectional synchronization link, synchronize the collected weight information of the food to be tested to mobile terminal 2 in real time, and / or receive the food record editing data returned by mobile terminal 2 to complete local consistency backup; wherein mobile terminal 2 can independently perform operations such as entering asynchronous food recording mode in response to the start command, calling the database, inputting temporary names, matching and binding food identifiers, generating custom dishes, and modifying weight status. The bidirectional synchronization link here specifically refers to the Bluetooth BLE dedicated communication channel established between electronic device 1 and mobile terminal 2. Each end maintains an independent synchronization status flag bit. After synchronization is completed, the MD5 hash value of the data at both ends is automatically verified. Synchronization is marked as complete only after they are completely consistent, avoiding the problem of asynchronous data updates on one side.

[0086] The aforementioned asynchronous food recording electronic device 1 also includes a Bluetooth module 14, a microphone module 15, and a local offline voice recognition chip 16. The main control processing unit 11, the Flash storage module 13, the Bluetooth module 14, the microphone module 15, and the local offline voice recognition chip 16 are mounted on the PCB board 60, which is located inside the electronic device 1. The weighing sensor 12, the Flash storage module 13, the Bluetooth module 14, the microphone module 15, and the local offline voice recognition chip 16 are all electrically connected to the main control processing unit 11.

[0087] The pickup module 15 is used to receive the user's voice temporary naming command after the hardware switch is turned on, and complete the local offline speech recognition to output the temporary naming text;

[0088] The local offline speech recognition chip 16 is an independent computing unit with built-in NPU computing power, acoustic model and noise reduction algorithm. It is responsible for performing analog-to-digital conversion, feature extraction and speech recognition operations on the raw audio stream output by the sound pickup module 15, and finally outputting structured temporary named text. It is the core computing power carrier for realizing offline speech command parsing.

[0089] In the accompanying extended embodiments, the above-mentioned electronic device 1 also includes a display module 90 and / or a touch button module 80.

[0090] In the asynchronous food recording mode of the extended embodiment of the above-mentioned electronic device 1, after collecting the weight information of the current food to be tested, the current weighing result is automatically locked, and then the corresponding temporary naming instruction input by the user is received; after the user confirms that the naming information is accurate and triggers the save operation, the temporary name is bound with the corresponding weight information to generate a temporary food record entry, and the weighing process of the next food to be tested is directly entered.

[0091] In one embodiment, when the weight value of the food to be measured collected by the weighing sensor 12 fluctuates less than a preset threshold within a preset time window, the weight is determined to be stable and the weighing result is locked. The main control processing unit 11 is also used to perform any one or more of the following operations: output a pulse signal to turn on the peripheral power supply circuit and wake up the voice pickup module 15 to receive the user's voice temporary naming command; when there is no valid voice command input, the power supply circuit is automatically disconnected to return the voice pickup module 15 to the power-off state; in the asynchronous food recording mode, when no food is detected in the weighing area, the main control processing unit 11 automatically controls the whole machine to enter a low-power standby state with a standby power consumption of less than 10μA, and automatically wakes up to enter the weighing process after the food to be measured is placed. The peripheral power supply circuit is implemented using an AO3400 MOSFET hardware switch, which is completely different from the traditional software-level standby and hibernation. The switching of this MOSFET hardware switch is not affected by the system software hibernation state. Even if the main control processing unit 11 is in an abnormal state of crash or program crash, the microphone module 15 will not generate static power consumption due to abnormal power supply. The power leakage problem of the inability to completely shut down in software standby mode is completely eliminated from the hardware level. The microphone module 15 has no static power consumption after power failure, which is the core hardware foundation for achieving ultra-low standby power consumption of the whole machine.

[0092] In this electronic device 1, the sampling core of the weighing sensor 12 and the system core of the main control processing unit 11 are powered independently. When no food is placed on the device, the weighing sampling core intermittently samples weight data at a low frequency of 1Hz, and the system core enters a deep sleep state. The standby power consumption of the whole device is controlled within 10μA. After the food to be tested is placed and the weight change threshold is triggered, the system core wakes up from the deep sleep state within 10ms and enters the full power weighing mode. This achieves ultra-low standby power consumption at the microampere level and ensures the response speed of weighing wake-up, completely solving the industry pain points of high standby power consumption and short battery life of traditional smart kitchen scales.

[0093] The aforementioned asynchronous food recording electronic device 1 includes a smart kitchen scale. Specifically, the smart kitchen scale in this embodiment includes, as follows: Figure 1The components shown include a panel 10, lens 20, faceplate 30, weighing feet 40, bottom shell 50, PCB board 60, MIC (microphone) 70, touch button module 80, display module 90, weighing sensor 12, and battery assembly. The PCB board 60 houses a main control processing unit 11, storage module 13, Bluetooth module 14, microphone module 15, and local offline voice recognition chip 16. The battery assembly provides stable power to all these components. The main control processing unit 11 uses the Jinghua Micro SD82P153 low-power weighing SoC. The weighing sensor 12 uses a strain gauge pressure sensor with a range of 0-5kg and an accuracy of 0.1g. The microphone module 15 is equipped with a local offline voice recognition chip 16 ENAS-A01 with integrated NPU computing power. The storage unit uses a 16MB SPI Flash with physical partitioning, where 2MB is allocated to the basic food storage sector, 8MB to the temporary cache sector, and 6MB to the permanent custom library sector. The three sectors have independent read / write addressing channels, avoiding data read / write conflicts by not occupying computing resources. An AO3400 N-channel MOSFET is connected in series as a hardware trigger switch in the power supply circuit between the microphone module 15 and the local offline voice recognition chip 16. The switch is only turned on when the main control outputs a 3.3V high-level pulse; otherwise, the microphone module 15 is completely powered off with no standby power consumption. The device is equipped with a low-power Bluetooth 5.2 module, which can be paired and linked with a health management APP on a mobile phone. Bluetooth data transmission uses an MD5 checksum retransmission mechanism, reducing the cross-terminal synchronization data packet misalignment rate to 0.

[0094] The above parameters can be adapted and adjusted according to kitchen scale products with different weighing ranges. This embodiment is only an example of optimal parameters and does not constitute a limitation on the scope of protection: In the standby state of the whole machine, only the peripheral scheduling core is in low-power standby operation, and the standby power consumption of the whole machine is controlled within 12μA. Compared with the same configuration of smart kitchen scales with voice function, the battery life is increased from the usual 7 days to more than 32 days. Preset parameter configuration: The fluctuation threshold within the 200-millisecond time window for weight stability determination is set to 0.2g. The fuzzy matching calculation score threshold is 80 points by default at the factory and supports user customization. The microphone module will automatically power off if there is no effective voice input for 10 seconds after wake-up. The current food recording is determined to be completed when the panel weight returns to zero for 10 seconds. The whole machine enters sleep state after 3 minutes of no operation.

[0095] This application provides an asynchronous cross-platform food ingredient recording system, such as... Figure 3 As shown, it includes:

[0096] An electronic device 1 and a mobile terminal 2 are configured with a weighing sensor 12 and a main control processing unit 11. The electronic device 1 and the mobile terminal 2 establish a two-way data synchronization connection through a wireless communication link.

[0097] Electronic device 1 is used to respond to the asynchronous mode trigger command issued by mobile terminal 2 to enter the asynchronous food recording mode, or to maintain the normal weighing standby state; to perform weighing operations on X kinds of food to be tested in sequence, where X is a positive integer ≥2; after any food to be tested is placed in the weighing area of ​​electronic device 1, the weighing operation is performed to collect and obtain the weight information of the food to be tested, and the weight information is pushed to mobile terminal 2 in real time through wireless communication link;

[0098] Mobile terminal 2 establishes a communication connection with electronic device 1 to enter its own asynchronous food recording mode in response to a start command, and / or remotely triggers electronic device 1 to enter asynchronous food recording mode via a wireless communication link. It performs remote parameter editing and configuration on electronic device 1 through wireless communication. After receiving the weight information of each food item to be tested, it receives the temporary naming command input by the user that corresponds one-to-one with the current food item to be tested, binds the temporary name to the synchronized weight information, and generates at least two independent temporary food record entries locally. The weighing and temporary naming process of all food items to be tested can be completed in multiple time periods.

[0099] Mobile terminal 2 is also used to perform any one or more of the following operations:

[0100] The database is called to filter out at least one food identifier that corresponds to the temporary naming instruction. The weight information and corresponding nutritional parameters of the food to be tested are combined to calculate and generate the actual nutritional data of the food and output it for display.

[0101] The generated temporary food ingredient record entries and nutritional data are backed up and synchronized to the local electronic device 1 to complete the data backup, so as to achieve consistent updates of food ingredient record data at both ends.

[0102] Receive a custom dish generation instruction, combine at least two independent temporary ingredient record entries into a complete custom dish, and generate a custom dish identifier;

[0103] In response to a weight status modification command, at least one previously unconfigured switchable weight attribute label is added to the generated custom dish; the collected or entered weight value, or the single-serving weight value calculated from the user-input serving value, is associated and stored with the selected target weight attribute label; during the binding configuration of this weight attribute label, the total nutritional data already stored for the custom dish is directly used; based on the currently active weight attribute and the corresponding bound weight value, the conversion mapping relationship between the stored total nutritional data and the weight value corresponding to the currently active weight attribute is invoked to generate the nutritional data for the corresponding serving size and output it for display;

[0104] A bidirectional synchronization link is configured in the wireless communication link between electronic device 1 and mobile terminal 2. It is used to synchronize the weight information collected by electronic device 1 to mobile terminal 2 in real time, and / or receive the food record editing data returned by mobile terminal 2 and automatically synchronize and back it up to the local device of electronic device 1, so as to complete the consistency verification and retention of the data at both ends.

[0105] The data synchronization between the aforementioned electronic device 1 and mobile terminal 2 adopts the MD5 checksum retransmission mechanism, reducing the data packet misalignment rate of cross-terminal synchronization to 0. The same electronic device 1 supports binding multiple authorized mobile terminals 2. The main control processing unit 11 allocates a dedicated continuous physical storage address segment for each bound terminal's newly created temporary food record entry. Temporary records of different terminals are allocated independent physical address segments in the storage unit of electronic device 1, eliminating the risk of cross-account data overwriting. When the communication link between electronic device 1 and mobile terminal 2 is interrupted, both ends cache the unsynchronized food record data. After the communication link is re-established, the breakpoint resume synchronization operation is automatically triggered, preventing data loss or duplicate uploads. The asynchronous food record mode supports temporary record retention for up to 72 hours. If electronic device 1 is powered off and then powered on again, the stored temporary food records will not be lost. After waking up, new entries can be added directly on the basis of the original incomplete temporary records.

[0106] The aforementioned asynchronous food recording cross-terminal linkage system can be a cross-terminal linkage system composed of a smart kitchen scale and a mobile APP.

[0107] This application provides an asynchronous food recording method, which is applied to an electronic device 1 equipped with a weighing sensor 12, a sound pickup module 15, a local offline voice recognition chip 16, a Flash storage unit and a main control processing unit 11; the electronic device 1 includes an electronic scale, a kitchen scale, and other kitchen equipment with intelligent weighing functions.

[0108] The asynchronous food recording method is as follows: Figure 4 As shown, it includes the following steps:

[0109] S101, Electronic device 1 responds to the start command and enters asynchronous food recording mode;

[0110] Specifically, after electronic device 1 completes the entire power-on process, weighing zero-point calibration, and screen illumination, the peripheral scheduling core maintains a low-power standby state by default, retaining only the basic detection capabilities of the interaction links (i.e., voice wake-up, button triggering, and touch operation). The overall standby power consumption is ≤10μA, and there are no invalid background processes consuming computing resources. Users can input the start command through any of three methods: voice wake-up, pressing physical function buttons, or selecting the corresponding function icon on the touch screen. After the device responds, it starts the asynchronous food recording mode; the device display screen simultaneously pops up an operation selection interface, where users can choose two parallel operation paths:

[0111] Path 1: Create a new independent index folder "Dish N". The main control processing unit 11 automatically allocates a dedicated continuous physical storage address segment for "Dish N" in the temporary cache sector of the Flash storage unit. All subsequent ingredient records under this dish will be written to this continuous address space first. Only when the capacity of this continuous address space is exhausted will the main control processing unit 11 schedule other free sectors to take over the overflow data.

[0112] Path 2: Directly select the created historical incomplete index folder "Dish Y". The main control processing unit 11 will automatically jump to the end address of the dedicated continuous physical storage address segment corresponding to the folder. Subsequent new records will be appended to the existing data without overwriting the previously stored historical food data.

[0113] Where "Dish N" is the independent index folder generated by the user's current creation operation, and N is the unique incremental sequence number of the newly created folder; "Dish Y" is the historical incomplete index folder stored in the device, and Y is the unique index number corresponding to the historical folder; when there are no historical incomplete index folders in the device, the newly created "Dish N" corresponds to N=1; when there are M historical incomplete index folders in the device, the value range of X is 1≤Y≤M, and the newly created "Dish N" corresponds to N=M+1; M is a non-negative integer.

[0114] The above user startup commands cover three types of operations: commands to enable asynchronous ingredient recording mode, commands to select new "Dish N", and commands to select the unfinished historical folder "Dish Y".

[0115] Example Implementation Scenario: After the smart kitchen scale is powered on, the user selects the "Temporary Record" item to start the asynchronous food recording mode. The display screen shows two existing incomplete items, "Dish 1" and "Dish 2". After the user selects the "New" option, the main control processing unit 11 automatically generates a new index folder "Dish 3" and directly enters the recording waiting state of this folder. Subsequent food weighing and temporary recording operations can be performed directly. Alternatively, the display screen shows three existing incomplete items, "Dish 1", "Dish 2", and "Dish 3". After the user selects "Dish 3", they are directly redirected to the recording waiting state of this historical folder, where new items can be added based on the existing temporary food recording items.

[0116] S102. Perform weighing operations on X kinds of ingredients to be tested in sequence and receive the user's temporary naming instructions to generate independent temporary ingredient record entries, where X is a positive integer ≥2;

[0117] The specific operation is as follows: After any food item to be tested is placed in the weighing area of ​​electronic device 1, electronic device 1 performs a weighing operation, collects and obtains the weight information of the food item to be tested; then electronic device 1 receives the corresponding temporary naming instruction input by the user, binds the temporary name with the collected weight information, and generates an independent temporary food item record entry; repeat the above operation, and the weighing and temporary naming of all food items to be tested can be completed in multiple time periods, and at least two independent temporary food item record entries will be generated in the end.

[0118] More specifically, the operation process consists of four consecutive steps:

[0119] S1021, Weight Stability Locking: The user places the food to be tested on the weighing device. The pressure weighing sensor 12 on the weighing device collects the analog weight signal on the bearing panel in real time and transmits it to the main control processing unit 11 for digital filtering. When the detected weight value fluctuates by less than 0.2g within a preset time window of 200 milliseconds, it is determined that the weight of the food to be tested is stable. The weighing processing unit locks the stable weight value and outputs a high-level weight confirmation pulse signal to the hardware trigger switch between the sound pickup module 15 and the local offline voice recognition chip 16.

[0120] S1022, Temporary Naming Voice Acquisition: After receiving the weight confirmation pulse signal, the hardware trigger switch closes to supply power, waking up the voice pickup module 15 from a completely power-off state. It acquires the user-inputted temporary naming voice command for the food ingredient, transmits the analog voice signal to the local offline voice recognition chip 16, extracts the voice feature vector, completes the mapping conversion, outputs the temporary name text of the food ingredient to be tested, and pushes it to the display screen. The user can confirm the text via button trigger or touch operation. If the recognition is incorrect, the voice input can be directly retried without exiting the current recording process. If the voice pickup module 15 does not acquire a valid voice command within 10 seconds of waking up, the hardware trigger switch automatically disconnects, and the voice pickup module 15 returns to a completely power-off state, avoiding unnecessary power consumption.

[0121] S1023, Temporary Entry Packaging and Storage: The peripheral scheduling core packages the confirmed temporary named text with a stable weight value, generating a binary data packet with a millisecond-level system timestamp. This data packet is then written to the dedicated physical storage address segment corresponding to "Dish N" within the temporary cache sector. A temporary marker is added to this data packet, generating an independently addressable temporary ingredient record entry. When the remaining space in the dedicated contiguous physical storage address segment is insufficient, the peripheral scheduling core automatically allocates an adjacent extended address segment within the temporary cache sector and updates the address mapping table of the index folder, preventing data write failures.

[0122] S1024, Single Record Completion Sleep Mode: When the weighing device detects that the weight on the bearing panel has returned to zero and has remained unchanged for 10 seconds, the peripheral scheduling core determines that the current single food item record is complete, immediately outputs a low-level signal to the hardware trigger switch, disconnects the power supply circuit of the microphone module 15, and allows the microphone module 15 to return to a completely power-off state; if there is no operation within the next 3 minutes, after the power is turned off to the non-essential modules of the whole machine, the weighing device automatically enters a sleep mode, and all whole machine data written to the temporary cache sector will not be lost.

[0123] This step incorporates two fault-tolerant verification logics:

[0124] Invalid weight filtering: When the weight of the food to be measured is lower than the preset minimum weighing threshold, the electronic device 1 automatically triggers a pop-up prompt and does not generate invalid temporary food record entries, thus avoiding the occupation of database storage space by invalid data of zero weight or microweight. This preset minimum weighing threshold can be customized according to the range and accuracy of the weighing sensor 12. For example, for a kitchen scale with a range of 5kg and an accuracy of 1g, the threshold is set to 2g by default. Weights below this value are judged as invalid weight data generated by residual debris on the scale surface or accidental touch.

[0125] Name conflict avoidance: When a user-inputted temporary name conflicts with an existing food identifier in the database, the main control processing unit 11 automatically adds a unique suffix identifier to the newly generated temporary food record entry and generates an independent storage mapping path for the new entry. This unique suffix identifier adopts a combination of "timestamp + random checksum". For example, if the user inputs "tomato scrambled eggs" twice as a temporary name, the second generated entry will be automatically named "tomato scrambled eggs_20260822_7291", thus avoiding the problem of name duplication from the source.

[0126] Exemplary implementation scenario:

[0127] After selecting to create "Dish 3", the user places the flour needed for this cooking on the smart kitchen scale for weighing, and then the page displays a text box with the weighing value to be entered.

[0128] The user inputs the voice command "white flour", and the text box displays that the system recognizes it as "white cotton". The user can delete the text and re-input the voice command. The text box will then display that the system recognizes it as "white flour". The user can confirm the text, and the system will save the temporary food item record, completing the weighing and temporary recording of the food item.

[0129] Users weigh flour, chives, eggs, shrimp, and pork in sequence, generating corresponding temporary food record entries: "flour" 638g, "chives" 345g, "shrimp" 266g, "lean pork" 332g, and "eggs" 234g.

[0130] After the user completes the preparation work such as cleaning the above ingredients, restart the smart kitchen scale that has entered the dormant state. Wake it up by pressing the button, select the "Temporary Record" item in sequence, and then select the "Dish Three" item. The interface will directly jump to the recording waiting state of the history folder. The user weighs and records the amount of peanut oil and soy sauce in sequence. The system will continue to add new items on the basis of the original temporary ingredient record items, namely "peanut oil" 25g and "light soy sauce" 18g.

[0131] After the user finishes making the dumplings, they restart the smart kitchen scale, which has been in sleep mode. By pressing a button to wake it up, the user selects the "Temporary Record" item and then the "Dish Three" item. The interface then jumps directly to the record waiting state of the history folder. The user weighs the dumplings and finds that the actual weight of the dumplings is 2146g (the weight is increased due to the addition of water when making the dough or filling, but the nutritional elements remain unchanged). The system continues to add a new item to the existing temporary ingredient record. The user enters the temporary name "water" and manually changes the weight of the water to 288g.

[0132] S103. Select any temporary food ingredient record entry and perform food identifier binding operation. The main control processing unit 11 calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and combines the weight information of the food to be tested with the corresponding nutritional parameters to calculate and generate the actual nutritional data of the food and output it for display. Repeat this operation to complete the food identifier binding operation of at least two temporary food ingredient record entries in multiple time periods.

[0133] "Fuzzy matching operation" is the operation logic of the main control unit to calculate the matching score based on three dimensions: first, the character overlap between the temporary name and the standard food name; second, the matching degree between the temporary name and the full pinyin / first letter of the standard food name; and third, the association mapping matching degree between the temporary name and the pre-stored ingredient aliases. The preset threshold for the operation is set to 80 points by default. Candidate food identifiers with scores higher than this value can be entered into the selectable drop-down list. This threshold can be customized and adjusted by users according to their own usage habits.

[0134] Specifically, the operation process consists of three consecutive steps:

[0135] S1031, Food Label Binding: After all ingredients have been weighed, the user can access the data matching page by pressing the "Menu" button on the device. The main control processing unit 11 will push all temporary ingredient record entries under the "Dish N" exclusive address segment to the display screen one by one. The user can directly select the corresponding entry on the device and bind it to the food label in the basic food database sector.

[0136] S1032, Nutritional Conversion of a Single Ingredient: The main control processing unit 11 retrieves the nutritional parameters per 100 grams corresponding to each bound standard ingredient item, obtains the actual nutritional data of a single ingredient through a proportional conversion formula, and then adds up the nutritional data of all single ingredients to obtain the total calories, total protein, total fat and total carbohydrate content of the current dish, and pushes it to the display interface for display. The calculation formula is: Nutritional data of a single ingredient = actual weight of the ingredient ÷ 100g × nutritional parameters per 100 grams of the corresponding standard ingredient.

[0137] S1033. Permanent Storage of Custom Dishes: The main control processing unit 11 receives the instruction to generate a custom dish, combines at least two independent temporary ingredient record entries that have completed food identification binding into a complete custom dish, generates a custom dish identifier, and stores it in the database. Users can directly input the name of a custom dish through the physical buttons on the weighing device. The main control processing unit 11 migrates the total weight, total nutritional data, and full ingredient detail data of the dish from the temporary cache sector to the permanent custom library sector for storage, and removes the temporary tag bit of the data packet. All dish entries in the permanent custom library sector obtain the same weight coefficient as the entries in the basic food library sector in the retrieval and sorting algorithm built into the main control processing unit 11. When the user inputs voice keywords or touch input text keywords, the entries in both types of sectors participate in the sorting simultaneously. The retrieval and sorting algorithm prioritizes matching the entries that the user has used most frequently in the past 7 days. Entries with a matching degree reaching a preset threshold appear together in the list of selectable ingredients for the user to directly call. This solution grants custom dish labels the same search weight as the system's pre-set standard food labels, with a search response time of no more than 300ms. Compared to the average 1000ms search speed of conventional smart kitchen scale apps, this represents an efficiency improvement of over 70%. When the permanent custom database sector storage space reaches 90%, the main control processing unit 11 automatically prompts "Clear historical dish records older than 30 days?" to prevent storage overflow.

[0138] Example implementation scenario: After completing the cooking task, the user edits the ingredients for the dish.

[0139] Wake up the smart kitchen scale that has entered sleep mode, and after selecting the "Temporary Record" item and the "Dish 3" item in sequence, the interface will directly jump to the record waiting state of the history folder, that is, the display screen will show all the temporary ingredient record items in the "Dish 3" folder.

[0140] When a user selects the "white flour" item, the system automatically switches to search mode. The user changes the search keyword to "flour," and the drop-down menu displays all ingredient names related to "flour" in the local food identifiers. The user selects "wheat flour (standard flour)" and confirms, thus completing the binding of that ingredient item. The user continues to bind other ingredients to the local food identifiers in the database: "chives" is corrected to "chives," "shrimp" to "frozen shrimp," "lean meat" to "lean pork," "peanut oil" to "COFCO Original Peanut Oil," "light soy sauce" to "lightly salted light soy sauce," and "eggs" to "free-range chicken eggs."

[0141] The system updates the names of each item according to the user's selection, and calculates the calories, protein, fat and carbohydrate content of each ingredient based on the bound local food identification information and the actual weight of each ingredient. Thus, the total calories of dish three are 3720.49 kcal, total protein is 227.2g, total fat is 88.91g and total carbohydrate is 493.93g, and the results are displayed on the screen.

[0142] After binding, the user returns to "Dish 3", selects to change it to "Steamed Dumplings with Chives and Pork", confirms, and saves it to the permanent custom library sector. The raw weight of each 100g of raw dumplings (raw weight) of the Steamed Dumplings with Chives and Pork is 173.4 kcal, 10.6g of protein, 23.0g of carbohydrates, and 4.1g of fat.

[0143] Supporting extended implementation examples:

[0144] In the incremental nutrition calculation embodiment, the main control processing unit 11 can also perform the following operations on custom dishes: In response to the addition, deletion, or portion adjustment of ingredients in an already generated custom dish, incremental nutrition calculation is performed only on the modified single target ingredient item, while the original pre-stored nutritional parameters of the unmodified ingredients are directly reused. When a user adds, deletes, or adjusts the portion of an already generated custom dish, the system does not need to recalculate all the nutritional data of all ingredients in the entire dish. Incremental calculation is performed only on the modified single ingredient item, while the nutritional parameters of the remaining unmodified ingredients are directly reused from the original pre-stored data. The refresh response speed after editing a custom dish is shortened from the usual 800ms to less than 150ms, significantly improving the smoothness of operation in high-frequency editing scenarios.

[0145] In the multi-weight label configuration embodiment, the main control processing unit 11 can also perform the following operations on custom dishes: Responding to a weight status modification command, the main control processing unit 11 adds at least one switchable weight attribute label to the generated custom dish and enters the corresponding value; during the addition and configuration of the weight attribute label, the total nutritional data already stored in the custom dish is directly used. Here, "directly using the total nutritional data already stored in the custom dish" specifically means that the sum of the core nutritional parameters such as total protein, total fat, and total carbohydrates of all original ingredients in the custom dish remains unchanged; only different dimensions of weight reference values ​​are added, without altering the overall nutritional baseline of the dish itself, thus avoiding logical deviations in subsequent nutritional conversions. The newly added weight attribute label includes at least one of cooked weight and serving size. The initial default weight attribute label bound to a custom dish is raw weight. After the custom dish is cooked, the electronic device 1 collects the total cooked weight of the dish through the weighing sensor 12, adds a cooked weight attribute label to the custom dish and binds the collected cooked weight value. The total nutritional data of the dish associated with the cooked weight attribute label is consistent with the total nutritional data corresponding to the raw weight of the custom dish. And / or, the custom dish is divided into multiple independent equal units. The number of servings input by the user is received, and the pre-stored total raw weight value of the custom dish is directly called to automatically calculate and generate a single serving base weight value. A serving size attribute label is added to the custom dish and bound to the calculated single serving weight value. The nutritional data corresponding to a single serving of ingredients is directly mapped and generated based on the serving size attribute label. The total nutritional data associated with the serving size attribute label is consistent with the total nutritional data corresponding to the raw weight of the custom dish. Users can choose not to trigger any weight status modification commands and directly use the default raw weight label to complete subsequent nutritional conversions, and / or choose to trigger weight status modification commands to add any one or more custom weight attribute labels to complete the configuration. After the user collects the cooked weight value of the custom dish, the system automatically generates a raw-to-cooked conversion coefficient of "total raw weight - total cooked weight" and stores it persistently. When the user weighs any portion of the cooked dish later, the system can directly call the pre-stored conversion coefficient to calculate the corresponding raw weight of the ingredients and automatically match the corresponding nutritional data, eliminating the need for the user to manually enter the conversion coefficient and completely solving the cumbersome problem of manual table lookup required for raw-to-cooked conversion in traditional solutions. When the cooked weight value entered by the user exceeds 150% of the total raw weight or is less than 30%, the system automatically triggers an exception verification pop-up window, prompting the user to confirm whether there are any operational errors such as missing ingredients or unpeeled containers during the cooked weight weighing, to avoid logical errors in subsequent nutritional conversions caused by abnormal weight values.

[0146] Exemplary implementation scenario: (1) After the user steams all the leek and pork dumplings, the total cooked weight is 1870g. The user enters the "Leek and Pork Dumplings" item, selects the new "cooked weight" attribute tag, and enters the value. The system calculates that each 100g of dumplings contains 199.0kcal, 12.1g of protein, 26.4g of carbohydrates, and 4.8g of fat. When the user takes 200g of dumplings, the system can directly convert the corresponding calories to about 398kcal.

[0147] (2) The user made a total of 107 steamed dumplings. After entering the "Chive, Pork and Three Delicacies Steamed Dumplings" item and selecting the "Servings" attribute tag, the user entered the value. The system calculated that each steamed dumpling contained 34.8 kcal, 2.1 g of protein, 4.6 g of carbohydrates and 0.8 g of fat. When the user took 16 steamed dumplings, the system could directly convert the corresponding calories to approximately 555.3 kcal.

[0148] Cross-platform sharing and retrieval optimization implementation: The main control processing unit 11 can also perform any one or more of the following operations on custom dishes:

[0149] (1) The main control processing unit 11 synchronizes the stored custom dish identifiers to third-party devices to realize cross-device sharing of custom dish identifiers;

[0150] (2) The generated custom dish identifier can be exported as an independent data package containing total nutritional data and multiple sets of weight attribute labels. After importing the data package, third-party devices can directly reuse all the nutritional conversion logic of the custom dish. The independent data package is encapsulated in a lightweight JSON format and contains only three core data types: dish name, total nutritional parameters, and multiple sets of weight attribute values. It does not involve user privacy information and can be quickly shared through various methods such as QR code and Bluetooth transmission. It supports cross-brand smart weighing terminals and / or mobile terminals for compatible import.

[0151] (3) The main control processing unit 11 responds to the search command input by the user, obtains the total nutritional data within the custom dish identifier, and outputs and displays it;

[0152] (4) The main control processing unit 11 responds to the user's input search command, retrieves the baseline total nutrition data associated with the custom dish identifier, multiple sets of switchable weight attribute tags and corresponding dimension nutrition mapping relationships, and outputs and displays the corresponding dimension nutrition details data;

[0153] (5) In the retrieval and sorting algorithm of the main control processing unit 11, the custom dish identifier and the system's preset standard food identifier have the same retrieval weight. Priority is given to matching the entries with the highest usage frequency in the past 7 days. Entries with matching degree meeting the preset threshold are pushed to the interactive interface for the user to select. The retrieval response time is ≤300ms. Compared with the average retrieval speed of 1000ms of the conventional smart kitchen scale APP, the efficiency is improved by more than 70%. This retrieval and sorting algorithm can be deployed locally on electronic device 1 or mobile terminal 2. Here, "matching degree meeting the preset threshold" specifically means that the character similarity between the user's input retrieval keywords and the food identifier name is higher than 80%. All entries that meet this condition will be sorted and pushed according to the usage frequency from high to low to avoid a large number of irrelevant entries occupying the interactive interface.

[0154] (6) When the user enters a temporary naming command, the system automatically matches the candidate list of food labels with a similarity of ≥85% in the database, and supports one-click selection to complete the binding, without the user having to manually enter the complete ingredient name;

[0155] (7) The search ranking algorithm has a built-in custom dish-specific weight factor. This weight factor has a higher priority than the weight of the system's preset standard food identifiers. The search ranking position of user-defined dishes is always ahead of standard food identifiers with the same matching degree. The default value of this custom weight factor can be set to 1.2. The ranking score of custom dishes with the same matching degree will be multiplied by this coefficient, so that the frequently used dishes created by users are always ranked at the top of the search results.

[0156] (8) When the main control processing unit 11 responds to the weighing command, when the user weighs the custom dish, the electronic device 1 can directly calculate the nutritional data of the corresponding portion based on the real-time weighing weight collected at the moment.

[0157] (9) The main control processing unit 11 responds to the custom dish weighing command, identifies the target weight attribute dimension corresponding to the current weighing operation, directly retrieves the mapping relationship between the pre-stored total nutrition data and the corresponding weight attribute label under the custom dish identifier, and generates the corresponding portion of accurate nutrition data based on the real-time weighing weight collected at the moment and outputs and displays it.

[0158] This application provides a method for generating custom dishes, which is applied to an electronic device 1 equipped with a weighing sensor 12 and a main control processing unit 11;

[0159] This method is as follows Figure 5 As shown, it includes the following steps:

[0160] S201, Electronic device 1 responds to the start command and enters the food weighing and recording mode;

[0161] S202, the main control processing unit 11 receives the food input instruction, triggers the first input path or the second input path, and generates at least two independent food record entries.

[0162] The first input path is the asynchronous food recording mode: Electronic device 1 sequentially performs weighing operations on X kinds of food to be tested. After any food to be tested is placed in the weighing area of ​​electronic device 1, the weight information of the food to be tested is collected. Then, the temporary naming instruction corresponding to the food to be tested is received by the user. The temporary naming instruction is bound to the collected weight information to generate an independent food record entry, where X is a positive integer ≥2. The above operation is repeated.

[0163] The second input path is the pre-identification matching path: Electronic device 1 first receives at least one food identifier selected by the user, then triggers the weighing operation to collect the weight information of the corresponding food to be tested, binds the selected food identifier with the corresponding collected weight information, and generates an independent food record entry.

[0164] S203, the main control processing unit 11 receives the custom dish generation instruction, combines at least two independent ingredient record entries into a complete custom dish, and generates a custom dish identifier.

[0165] The method for generating custom dishes also includes the following steps: selecting any temporary ingredient record entry generated by the first input path and performing a food identifier binding operation; the main control processing unit 11 calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and, combined with the weight information and corresponding nutritional parameters of the ingredient to be tested, calculates and generates the actual nutritional data of the ingredient and outputs and displays it.

[0166] The above-mentioned method for generating custom dishes breaks the limitation of traditional smart kitchen scales that only support the function of pre-set fixed standard ingredients, and realizes the "standardization of user-defined dishes": user-made home-cooked meals, fitness meals and other non-standard combination dishes can be converted into searchable identifiers that are completely equivalent to the standard foods built into the system after one weighing and entry. When reusing the dish and recording nutrition intake in the future, there is no need to repeatedly enter multiple ingredient entries, which greatly reduces the threshold for nutrition recording in high-frequency self-made meal scenarios.

[0167] Supporting extended implementation examples:

[0168] In the incremental nutrition calculation embodiment, the main control processing unit 11 responds to the weight status modification command by adding at least one switchable weight attribute label to the generated custom dish and entering the corresponding weight value or serving size value; during the process of adding and configuring the weight attribute label, the total nutrition data already stored for the custom dish is directly used. The newly added weight attribute label includes at least one of cooked weight and serving size, and the weight attribute label initially bound to the custom dish by default is raw weight. The operation scenario corresponding to the cooked weight state is as follows: After the custom dish is cooked, the electronic device 1 collects the total cooked weight of the dish through the weighing sensor 12, adds a cooked weight attribute label to the custom dish and binds the collected cooked weight value; the total nutritional data of the dish associated with the cooked weight attribute label is consistent with the total nutrient data corresponding to the raw weight of the custom dish. The operation scenario corresponding to the serving size state is as follows: The custom dish is divided into multiple independent equal units. The number of servings input by the user is received, and the pre-stored total raw weight value of the custom dish is directly called to automatically calculate and generate a single serving base weight value. A serving size attribute label is added to the custom dish and bound to the calculated single serving weight value; the nutritional data corresponding to a single serving of ingredients is directly mapped and generated based on the serving size attribute label. The total nutritional data associated with the serving size attribute label is consistent with the total nutrient data corresponding to the raw weight of the custom dish.

[0169] All steps of the above-mentioned custom dish generation method can be executed across terminals in a linkage system consisting of electronic device 1 with weighing sensor 12 and mobile terminal 2: the food weighing operation is completed by electronic device 1, the temporary naming, food identification matching, and custom dish combination generation operation are completed by mobile terminal 2, and the weight information collected by weighing is transmitted to mobile terminal 2 in real time through a two-way synchronous link.

[0170] This application provides a custom multi-state weight calibration method for dishes, applied to an electronic device 1 equipped with a weighing sensor 12 and a main control processing unit 11, such as... Figure 6 As shown, it includes the following steps:

[0171] S301, in response to the command to complete the generation of the custom dish identifier, the main control processing unit 11 configures at least two switchable weight attribute tags for the generated custom dish; and / or, in response to the command to modify the weight status, the main control processing unit 11 adds at least one previously unconfigured switchable weight attribute tag to the generated custom dish.

[0172] S302, the main control processing unit 11 will calculate the single-serving weight value obtained by collecting or entering the weight value or the number of servings input by the user, and associate and store it with the selected target weight attribute label. In the process of binding and configuring the weight attribute label, the total nutritional data already stored for the custom dish will be directly used.

[0173] S303, the main control processing unit 11, based on the currently activated weight attribute and the corresponding bound weight value, calls the conversion mapping relationship between the stored total nutrition data and the benchmark weight value corresponding to the currently activated weight attribute, generates the corresponding portion of nutrition data and outputs and displays it.

[0174] All steps of the above-mentioned custom dish multi-state weight calibration method can be executed across terminals in a linkage system consisting of electronic device 1 with weighing sensor 12 and mobile terminal 2: the generation of custom dish identifier, modification of weight state and nutritional conversion are completed by mobile terminal 2, the acquisition of cooked weight values ​​is completed by weighing sensor 12 of electronic device 1, and the acquired weight data is transmitted back to mobile terminal 2 in real time through a two-way synchronous link to complete the binding.

[0175] The above calibration process does not modify the hardware zero-point parameters of the weighing sensor 12, but only completes the mapping and binding of different weight dimensions with total nutrient data at the software level.

[0176] The above calibration logic is completely different from the traditional zero-point calibration of sensor hardware. It belongs to the multi-weight dimension data calibration of the dish dimension. It does not modify the hardware parameters of the weighing sensor 12, but only supplements the weight reference benchmarks of the generated custom dishes in different scenarios at the software level, so as to realize accurate nutritional conversion in the scenarios of raw weight, cooked weight and portioning.

[0177] This application provides an asynchronous cross-terminal linkage method for food recording, which is applied to a linkage system consisting of an electronic device 1 equipped with a weighing sensor 12 and a main control processing unit 11 and a mobile terminal 2 connected through a wireless communication link; This method is as follows Figure 7 As shown, it includes the following steps:

[0178] S401, Mobile Terminal 2 responds to the start command and enters asynchronous food recording mode;

[0179] S402. Weighing operations are performed sequentially on X kinds of food to be tested and synchronized to mobile terminal 2, where X is a positive integer ≥ 2; after any food to be tested is placed in the weighing area of ​​electronic device 1, electronic device 1 performs a weighing operation, collects and obtains the weight information of the food to be tested, and pushes the weight information to mobile terminal 2 in real time; after receiving the weight information of any food to be tested, mobile terminal 2 receives the corresponding temporary naming instruction input by the user, binds the temporary name with the synchronized weight information, and generates an independent temporary food record entry;

[0180] S403. Select any temporary food ingredient record and perform a food identifier binding operation. Mobile terminal 2 calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and combines the weight information and corresponding nutritional parameters of the food ingredient to be tested to calculate and generate the actual nutritional data of the food ingredient and output it for display.

[0181] In the above-described linkage method, the weighing operation is performed on X kinds of ingredients sequentially, and the corresponding temporary naming command input by the user is received. The weighing and temporary naming of all ingredients to be tested can be completed multiple times across time periods, ultimately generating at least two independent temporary ingredient record entries. Mobile terminal 2 transmits the generated temporary ingredient record entries and nutritional data back to electronic device 1 for data backup, achieving consistent updates of ingredient record data at both ends. In response to the start command, mobile terminal 2 can either enter asynchronous ingredient recording mode or enter asynchronous ingredient recording mode of electronic device 1, using the wireless communication function of mobile terminal 2 to remotely edit and configure parameters on electronic device 1.

[0182] The temporal decoupling boundary of the "asynchronous food recording mode" in this linkage method not only includes the temporal separation of "weight acquisition" and "identifier matching", but also supports the asynchronous execution of "weighing operation" and "temporary naming operation" across devices and scenarios: users can quickly weigh all the food in the kitchen, temporarily store the original weight data locally on the scale, and then complete the batch temporary naming and food identification binding through the mobile phone in any scenario such as the living room or office after leaving the kitchen. The two operations are not limited by spatial location at all, further expanding the applicable boundaries of the asynchronous mode.

[0183] Supporting extended implementation examples:

[0184] Mobile terminal 2 can also perform one or more of the following operations:

[0185] (1) Receive custom dish generation instructions, combine at least two independent temporary ingredient record entries that have completed food identification binding into a complete custom dish, generate a custom dish identifier and store it in the local database;

[0186] (2) In response to the weight status modification command, add at least one switchable weight attribute label that has not been configured before to the generated custom dish; the main control processing unit 11 associates and stores the weight value of the collected or entered weight value or the single weight value obtained by calculating the number of portions entered by the user with the selected target weight attribute label. In the process of binding and configuring the weight attribute label, the total nutritional data of the custom dish that has been stored is directly used; based on the currently activated weight attribute and the corresponding bound weight value, the main control processing unit 11 calls the conversion mapping relationship between the stored total nutritional data and the benchmark weight value corresponding to the currently activated weight attribute, generates the nutritional data of the corresponding portion and outputs and displays it.

[0187] (3) The main control processing unit 11 allocates a dedicated continuous physical storage address segment for each newly created temporary food ingredient record. Subsequent newly added food ingredient records are directly appended to the end of the corresponding address segment without overwriting the stored historical food ingredient data. This storage mechanism is based on Flash physical partitioning. Each temporary food ingredient record is allocated at least 4KB of continuous dedicated address segment. When writing data, the "append without overwrite" rule is adopted. Even if the device loses power unexpectedly, the historical data written in the address segment will not be erased, thus ensuring data reliability from the hardware level.

[0188] (4) The asynchronous food recording mode supports temporary record retention for up to 72 hours. If the device loses power and is powered on again, the stored temporary food records will not be lost. After waking up, new entries can be added directly on the basis of the original incomplete temporary records. The 72-hour retention period is suitable for the food preparation cycle of most family users. Users can weigh all the food preparation ingredients on the first night and complete the food identification binding after cooking on the second day. It is not limited by time or scenario.

[0189] Cross-terminal bidirectional synchronization and multi-terminal isolation linkage implementation example: When a user completes any operation such as editing a temporary food record entry, generating a custom dish, or adding a weight attribute label on the mobile terminal 2, the mobile terminal 2 automatically backs up the edited food record data to the storage area of ​​the electronic device 1 equipped with the weighing sensor 12, thereby realizing bidirectional consistency verification and backup retention of food record data at both ends.

[0190] When the communication link between electronic device 1 and mobile terminal 2 is interrupted, both ends cache the unsynchronized food record data. After the communication link is re-established, the interruption resume synchronization operation is automatically triggered, so there will be no data loss or duplicate upload.

[0191] The same smart weighing electronic device 1 supports binding to up to 5 authorized mobile terminals 2. Customized food labels generated by different terminals are also physically isolated and stored locally on the scale. The main control processing unit 11 allocates an independent dedicated storage partition for each bound terminal. Temporary food record entries generated by different terminals are completely physically isolated, preventing the problem of food records from different users overwriting each other. This is suitable for the usage scenario of multiple family members sharing the same smart kitchen scale. When the Bluetooth communication between the electronic device 1 and the mobile terminal 2 is completely disconnected, the electronic device 1 can independently complete the weighing of all food and temporary record storage operations. All data is temporarily stored in the independent Flash partition on the scale, supporting offline retention for up to 72 hours. Once the communication link is restored, full data synchronization is automatically triggered, without interrupting the user's weighing process.

[0192] This collaborative method utilizes a bidirectional consistency verification and backup mechanism between electronic device 1 and mobile terminal 2, coupled with breakpoint resume logic after communication interruption, to achieve mutual backup of food record data between the two ends. This completely avoids the risk of food record loss due to device damage or accidental data deletion, as seen in traditional single-end storage solutions. Even if cross-end communication is temporarily interrupted, the generated food records will not be lost or duplicated, achieving an eventual consistency success rate of over 99.9%.

[0193] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0194] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. An asynchronous food ingredient recording method, characterized in that, Applied to electronic devices equipped with weighing sensors and main control processing units; The method includes the following steps: The electronic device responds to the start command and enters the asynchronous food recording mode; The system sequentially weighs X types of food ingredients to be tested and receives temporary naming instructions from the user, generating independent temporary food ingredient record entries, where X is a positive integer ≥ 2; Select any temporary food record entry and perform a food identifier binding operation. The main control processing unit calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and combines the weight information and corresponding nutritional parameters of the food to be tested to calculate and generate the actual nutritional data of the food and output it for display. The specific steps of sequentially weighing X types of food ingredients and receiving temporary naming instructions from the user are as follows: After any food ingredient is placed in the weighing area of ​​the electronic device, the electronic device performs a weighing operation, collects and obtains the weight information of the food ingredient; then the electronic device receives the corresponding temporary naming instruction input by the user, binds the temporary name with the collected weight information, and generates an independent temporary food ingredient record entry; the above operations are repeated.

2. The asynchronous food recording method according to claim 1, characterized in that, The main control processing unit receives a custom dish generation instruction, combines at least two independent temporary ingredient record entries into a complete custom dish, and generates a custom dish identifier.

3. The asynchronous food ingredient recording method according to claim 2, characterized in that, In response to the weight status modification command, the main control processing unit adds at least one switchable weight attribute label to the generated custom dish and enters the corresponding value; during the process of adding and configuring the weight attribute label, the total nutritional data already stored for the custom dish is directly used.

4. The asynchronous food recording method according to claim 2, characterized in that, The newly added weight attribute label includes at least one of cooked weight and number of servings, and the weight attribute label initially bound to a custom dish by default is raw weight; After the custom dish is cooked, the electronic device collects the total cooked weight of the dish through a weighing sensor, adds a cooked weight attribute tag to the custom dish and binds the collected cooked weight value. The total nutritional data of the dish associated with the cooked weight attribute tag is consistent with the total nutritional data corresponding to the raw weight of the custom dish. And / or, split the custom dish into multiple independent equal units, receive the number of portions input by the user, directly call the pre-stored total raw weight value of the custom dish to automatically calculate and generate the base weight value of a single portion, add a portion number attribute tag to the custom dish and bind it to the calculated single portion weight value, and directly map and generate the nutritional data corresponding to a single portion of ingredients based on the portion number attribute tag. The total nutritional data associated with the portion number attribute tag is consistent with the total nutritional data corresponding to the raw weight of the custom dish.

5. The asynchronous food ingredient recording method according to any one of claims 1-4, characterized in that, In the retrieval and sorting algorithm of the main control processing unit, the custom dish identifier and the system's preset standard food identifier have the same retrieval weight. Priority is given to matching the entries that the user has used most frequently in the past 7 days. Entries with a matching degree that meets the preset threshold are pushed to the interactive interface for the user to select. The retrieval response time is ≤300ms.

6. A method for generating custom dishes, characterized in that, Applied to electronic devices equipped with weighing sensors and main control processing units; The method includes the following steps: The electronic device responds to the start command and enters the food weighing and recording mode; The main control processing unit receives the food input instruction, triggers the first input path or the second input path, and generates at least two independent food record entries. The first input path is an asynchronous food recording mode: the electronic device sequentially performs weighing operations on X kinds of food to be tested. After any food to be tested is placed in the weighing area of ​​the electronic device, the weight information of the food to be tested is collected. Then, the temporary naming instruction corresponding to the food to be tested is received by the user. The temporary naming instruction is bound to the collected weight information to generate an independent food record entry, where X is a positive integer ≥2. The above operation is repeated. The second input path is a pre-identification matching path: the electronic device first receives at least one food identifier selected by the user, then triggers a weighing operation to collect the weight information of the corresponding food to be tested, binds the selected food identifier with the corresponding collected weight information, and generates an independent food record entry. The main control processing unit receives a custom dish generation instruction, combines at least two independent ingredient record entries into a complete custom dish, and generates a custom dish identifier.

7. A method for customizing the weight calibration of dishes in multiple states, characterized in that, An electronic device equipped with a weighing sensor and a main control processing unit includes the following steps: In response to the completion command for generating a custom dish identifier, the main control processing unit configures at least two switchable weight attribute tags for the generated custom dish. And / or, in response to the weight status modification command, the main control processing unit adds at least one previously unconfigured switchable weight attribute label to the generated custom dish; The main control processing unit will calculate the single-serving weight value obtained by collecting or entering the weight value or the number of servings input by the user, and associate and store it with the selected target weight attribute label. During the binding configuration of the weight attribute label, the total nutritional data already stored for the custom dish will be directly used. The main control processing unit, based on the currently activated weight attribute and its corresponding bound weight value, calls the conversion mapping relationship between the stored total nutrient data and the baseline weight value corresponding to the currently activated weight attribute, generates the corresponding portion of nutrient data, and outputs and displays it.

8. An asynchronous cross-platform method for recording food ingredients, characterized in that, It is applied to a linkage system consisting of electronic devices equipped with weighing sensors and main control processing units and mobile terminals connected through a wireless communication link; The method includes the following steps: The mobile terminal responds to the start command and enters asynchronous food recording mode; The weighing operation is performed sequentially on X kinds of food to be tested and synchronized to the mobile terminal, where X is a positive integer ≥2; after any food to be tested is placed in the weighing area of ​​the electronic device, the electronic device performs a weighing operation, collects and obtains the weight information of the food to be tested, and pushes the weight information to the mobile terminal in real time. After receiving the weight information of any food item to be tested, the mobile terminal receives the corresponding temporary naming instruction input by the user, binds the temporary name with the synchronized weight information, and generates an independent temporary food item record. Select any temporary food ingredient record and perform a food identifier binding operation. The mobile terminal calls the database, filters out at least one food identifier corresponding to the temporary name of the entry, and combines the weight information and corresponding nutritional parameters of the food ingredient to be tested to calculate and generate the actual nutritional data of the food ingredient and output it for display.

9. The asynchronous cross-terminal linkage method for recording food ingredients according to claim 8, characterized in that, When a user completes any of the following operations on the mobile terminal: editing a temporary food record entry, generating a custom dish, or adding a weight attribute label, the mobile terminal automatically backs up the edited food record data to the storage area of ​​an electronic device equipped with a weighing sensor, thereby achieving bidirectional consistency verification and backup of the food record data at both ends.

10. An asynchronous food recording electronic device, characterized in that, include: A weighing sensor is used to collect the weight information of the food to be measured placed in the weighing area; The main control processing unit is used to enter the asynchronous food recording mode in response to the start command; The storage module is pre-stored with food identifiers and corresponding nutritional parameters. It is used to store temporary food record entries, generated custom dish identifiers, and nutritional mapping relationships of at least one of multiple sets of weight attribute labels. The main control processing unit is also used to perform any one or more of the following operations: The database is called to filter out at least one food identifier that corresponds to the temporary naming instruction. The weight information and corresponding nutritional parameters of the food to be tested are combined to calculate and generate the actual nutritional data of the food and output it for display. Receive a custom dish generation instruction, combine at least two independent temporary ingredient record entries into a complete custom dish, and generate a custom dish identifier; In response to the weight status modification command, at least one switchable weight attribute label that was not previously configured is added to the generated custom dish; the main control processing unit associates and stores the weight value of a single serving obtained by calculating the weight value collected or entered, or the number of servings entered by the user, with the selected target weight attribute label. During the binding configuration of the weight attribute label, the total nutritional data already stored for the custom dish is directly used; based on the currently active weight attribute and the corresponding bound weight value, the main control processing unit calls the conversion mapping relationship between the stored total nutritional data and the baseline weight value corresponding to the currently active weight attribute, generates the nutritional data of the corresponding portion, and outputs and displays it; By establishing data interaction with the mobile terminal through a preset two-way synchronization link, the collected weight information of the food to be tested is synchronized to the mobile terminal in real time, and / or the food record editing data returned by the mobile terminal is received to complete local consistency backup. The mobile terminal can independently perform operations such as entering asynchronous food recording mode in response to the start command, calling the database, inputting temporary names, matching and binding food identifiers, generating custom dishes, and modifying weight status.

11. The asynchronous food recording electronic device according to claim 10, characterized in that, In asynchronous food recording mode, after collecting the weight information of the current food to be tested, the current weighing result is automatically locked, and then the corresponding temporary naming instruction input by the user is received; after the user confirms that the naming information is accurate and triggers the save operation, the temporary name is bound with the corresponding weight information to generate a temporary food record entry, and the process of weighing the next food to be tested is directly started.

12. An asynchronous cross-platform food ingredient recording system, characterized in that, include: An electronic device and a mobile terminal configured with a weighing sensor and a main control processing unit, wherein the electronic device and the mobile terminal establish a two-way data synchronization connection through a wireless communication link; The electronic device is used to enter the asynchronous food recording mode in response to the asynchronous mode trigger command issued by the mobile terminal, or to maintain the normal weighing standby state. The weighing operation is performed sequentially on X kinds of food to be tested, where X is a positive integer ≥2; after any food to be tested is placed in the weighing area of ​​the electronic device, the weighing operation is performed to collect and obtain the weight information of the food to be tested, and the weight information is pushed to the mobile terminal in real time through the wireless communication link. The mobile terminal establishes a communication connection with the electronic device to respond to a start command and enter its own asynchronous food recording mode, and / or remotely triggers the electronic device to enter the asynchronous food recording mode via a wireless communication link, and performs remote parameter editing and configuration on the electronic device through wireless communication. After receiving the weight information of each food item to be tested, it receives a temporary naming command input by the user that corresponds one-to-one with the current food item to be tested, binds the temporary name to the synchronized weight information of that item, and generates at least two independent temporary food record entries locally. The weighing and temporary naming process of all food items to be tested can be completed in multiple time periods. The mobile terminal is also used to perform any one or more of the following operations: The database is accessed to filter out at least one food identifier corresponding to the temporary naming instruction. The weight information and corresponding nutritional parameters of the food to be tested are combined to calculate and generate the actual nutritional data of the food and output it for display. The generated temporary food record entries and nutritional data are backed up and synchronized to the local electronic device to complete the data backup, so as to achieve consistent updates of food record data at both ends. Receive a custom dish generation instruction, combine at least two independent temporary ingredient record entries into a complete custom dish, and generate a custom dish identifier; In response to a weight status modification command, at least one previously unconfigured switchable weight attribute label is added to the generated custom dish; the collected or entered weight value, or the single-serving weight value calculated from the user-input serving value, is associated and stored with the selected target weight attribute label; during the binding configuration of this weight attribute label, the total nutritional data already stored for the custom dish is directly used; based on the currently active weight attribute and the corresponding bound weight value, the conversion mapping relationship between the stored total nutritional data and the weight value corresponding to the currently active weight attribute is invoked to generate the nutritional data for the corresponding serving size and output it for display; A bidirectional synchronization link is configured in the wireless communication link between the electronic device and the mobile terminal. It is used to synchronize the weight information collected by the electronic device to the mobile terminal in real time, and / or receive the food record editing data returned by the mobile terminal and automatically synchronize and back it up to the local of the electronic device, so as to complete the consistency verification and retention of the data at both ends.

Images